feat(cpp): add map type support

[yordis]

This PR adds map type support to the C++ backend, following the same pattern established in #1562 (core), #1583 (Go), and #1584 (MoonBit).

[alexcrichton]

cc @cpetig and @TartanLlama

[yordis]

@TartanLlama addressing your comments, the "why" behind things, I am effectively Junior in C++, please be patience with me here 🙏🏻 I am try to understand the intent and I will give it a second path

[cpetig]

If I were to implement this feature I would introduce a wit::map type which has the same layout as the lowered data. This way the data doesn't need to be copied unless the user code requests it (making map a lower cost abstraction).

On the other hand I just ran into an adjacent problem with list lowering (and avoiding re-allocation) in #1592 , so avoiding a copy in case of complex types might still be impossible - due to C++ type layout restrictions.

A std::map is of course more easy to use if you don't care about allocation and copy costs.

[yordis]

@cpetig @TartanLlama can you give it a pass again? 🙏🏻

Ideally, please share the intent of what you would like to see, I can figure out eventually the implementation but I am not qualify to the best practices or insights of C++. I can figure that out for sure, it would help to declare the intent so I can go off, study, and figure out what you want 😄

[TartanLlama]

Hmm I think that providing indexing functions for wit::map is a potential footgun. If the key type is an integral type, users who don't check the docs would likely assume that the argument to operator[] would be a key, rather than an index, but the code would compile fine. I think if we provide a zero-additional-copy wit::map type, it would have to have no indexing functions.

But I think in general there's a big tradeoff in performance vs ergonomics here. Ideally, I think we'd be able to configure whether we wanted a low-copy, low-usability type like wit::map vs a high-usability type that requires extra copies like std::unordered_map. What do you think @cpetig ?

[yordis]

I am gonna wait until @TartanLlama and @cpetig agree on the direction

[cpetig]

Don't feel disheartened by the complexity of designing proper language bindings, it took me more than a year to come up with something I mostly liked - and then @TartanLlama made a significant improvement by pointing out that moved arguments can be received into normal objects.

Sorry, but writing proper bindings is simply complex, and mapping map is more so.

[cpetig]

Hmm I think that providing indexing functions for wit::map is a potential footgun. If the key type is an integral type, users who don't check the docs would likely assume that the argument to operator[] would be a key, rather than an index, but the code would compile fine. I think if we provide a zero-additional-copy wit::map type, it would have to have no indexing functions.

I would not want to have functions which aren't part of the standard (unordered_)map - unless they are needed to construct the object within the bindings (or help construct these types in user code).

But I think in general there's a big tradeoff in performance vs ergonomics here. Ideally, I think we'd be able to configure whether we wanted a low-copy, low-usability type like wit::map vs a high-usability type that requires extra copies like std::unordered_map. What do you think @cpetig ?

I don't know which to prefer. This usually indicates that a generator option is a good solution. But I am quite sure that wit::unordered_map would be a better name for this thing. For C/C++/Rust I typically go with avoiding copying in the bindings even if the types get a little more difficult to use. In user code you can always add copying to more convenient types, but you can never remove it once it is done in the bindings.

Also I feel that wit::vector vs std::vector and wit::string vs std::string would be selected by the same option. This feels out of scope for just implementing WebAssembly/component-model#554

[yordis]

@TartanLlama @cpetig give it another pass please 🙏🏻