Locals/Watch view: Alternative Rendering for Empty Containers

Feature Request

When debugging in C++, multiple different types of variables display as "{...}", under cetrtain conditions, in the locals/watches views:

Objects on the stack are rendered this way when the pretty-printer is still loading, e.g. after just hitting a breakpoint. So are empty containers, and also empty optionals. Here, painter is an object whilst multiChannelAndStatuses is an empty container, and plotsEnabled is a non-empty container. I can't easily discern this by looking at them. It's hard to scan what are objects, what are containers or C-style arrays, what are other values with special handling.

Added to this that it's possible within the language to have invalid pointers, junk on the stack and values not yet initialised, it can become even harder to keep track easily of what's going on.

So I find this confuses my debugging, especially in the context of children that are lazily expanded, and especially when VS Code doesn't display the type of each object next to its name and value, as some other IDEs do. I keep having to expand children to verify if they really are empty, if they haven't loaded yet, or if I'm not sure if something is a container-like type or really an object that's not yet been expanded. This slows me down and makes me more likely to lose track of my train of thought for a second.

I'd prefer to see more specific rendering for the different symbols based on their types. I assume this is within the C++ extension, or between it and VS Code itself, since the debugger's pretty-printers must be working in order for me to expand the elements etc., and when using other languages, I get much more detailed information printed alongside the variable's name.

It would make more sense to me to use special values for some of these situations - for a container I'd rather see a brief summary of how many items are within, like [5 items], Sprocket - [5] or even just [5], and at least something like [] or {empty} for empty containers. Similarly, I think empty optionals could be rendered to show nullopt, empty, or {}, demarcating them from an unexpanded object. I find the experience in Qt Creator here, where the type is often listed in another column, and unexpanded objects may be previewed simply as the type name when there isn't a meaningful representation of their value. I think it also highlights invalid addresses and unitialised values in red, making it easy to search for lifecycle issues and null pointers nested deeply within some hierarchy.

All in all, I'm pretty open to what formats might be chosen, but, the main thins is that I don't think it makes sense to render all these different cases as the same {...} preview, as this then makes it harder to scan through the values, and it's not really adding anything to the window. Any kind of differentiation I think would help.

Thanks

No files, tests, or entry points are identified. Start by reproducing the C++ locals/watches cases shown—loading objects, empty containers, and empty optionals—and determine whether rendering belongs in the C++ extension or VS Code. Done means the affected values are visibly distinguishable without expanding children, with agreed representations for the reported cases.