Let me suggest a path forward:
This is the first iteration of the proposal. It is designed to solve some specific problems in Swift and the Objective-C Darwin SDKs, for which LLDB contains a lot of hardcoded data formatters written in C++.
There is no fundamental reason that precludes this from being useful for C++, but it’s not a priority of mine at this point in time. I would be just as excited to move the libcxx formatters out of LLDB, too, but I don’t yet have a good story to tell about the user interface (NatVis, DIL, …?) or about the compilation/distribution model (because of header-only libraries). As others pointed out, there is no reason we can’t do this in Clang, for example, via a custom attribute. It’s really just a matter of figuring out the language, which we’ve done for Swift but haven’t explored yet for C++.
This is version 1, and I’m convinced that we will need to make updates to format based on learnings from adopting it at scale. Pavel raised some concerns around having to maintain support for older versions, but I think we need to keep this in perspective with what this is going to replace. The existing data formatters for Objective-C frameworks also grow every year to keep up with changes to the internal implementation, and they are a lot larger than one interpreter. The interpreter can be unit-tested, the data formatters actually need a bot running the historic OS versions in order to be tested (or very elaborate mock data structures, but that’s not something we’ve historically done). So even though I know I’ll likely propose a version 2 in a year from now, I’m not concerned by this.
Based on the experience we’ll have gathered from porting Objective-C and Swift formatters to a system that compiles to bytecode, I’m also expecting to be better equipped to propose an actually good solution for C++.
All this is to say that I’m suggesting to build this out as an experimental feature for Swift and Objective-C, iterate on it based on the learnings we’ll have over the coming months and then restart the discussion about how/if we want to adapt this for C++.