Ditch wasm::vec for plain arrays? about wasm-c-api HOT 3 OPEN

Might I suggest std::unique_ptr<std::span<T>> for the C++ API instead?

No UB, no weird code (e.g. reinterpreting casts), perfectly safe, allows directly passing the pointer to C without a full copy, but it would break the "nothing after C++11" restriction that the API currently imposes.

from wasm-c-api.

Do you mean std::span<std::unique_ptr<T>>? For C++ alone, that would be possible, but I'm afraid it will make it harder to implement the C API on top of it efficiently, which currently relies on being able to reinterpret_cast a C++ API's vec to a C API's vec and vice_versa, which requires controlling the former's representation. That could be avoided, but I think only for the price of extra copying of the span pair.

Anyway, at this point I'd be comfortable requiring C++14 or 17, but it's a bit early to force everybody onto C++20.

from wasm-c-api.

Actually, neither std::span<std::unique_ptr<T>>, nor std::unique_ptr<std::span<T>>, make sense in this situation; one would need a union between the classes, i.e., a custom class. Note, unique_ptr<unique_ptr<T>[]> wouldn't be safe either: if std::unique_ptr were implemented in any stdlib as a struct larger than just the single pointer, then reinterpretation could be UB (not 100% sure, but if it's not, the results would be nonsense anyway).

As for updating the minimum language standard in use, I'd suggest at least checking out what versions implementations are currently using for their own Wasm VMs and other code. If no Wasm VM is written <= C++11, it would be wierd for the API to be in <= C++11.

(and yes, as having seen many libraries' reactions to C++20, I agree that it may be too new to push)

But, considering the lack of attention that this issue has been given, maybe the vec type does an okay job after all?

from wasm-c-api.