Ditch wasm::vec for plain arrays?

[rossberg]

The main purposes of wasm::vec are:

• bundle an arrays and its size,
• handle ownership of the elements (and the array),
• allow casting from and to plain C arrays without copying.

The latter point is e.g. relevant to enable implementing the C API in terms of the C++ one, where vectors need to be passed back and forth in both directions. In contrast, adopting and casting from a C array is not possible with e.g. std::vector (also, std::vector implies exceptions).

Yet, the vec abstraction is fairly complex, and may not carry its own weight. A (safe) alternative would be to use unique_ptr<unique_ptr<T>[]>. However, that would require to reinterpret_cast between this type and plain T[] -- which works on all compilers I have checked, but has the UB smell to it.

[ghost]

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.

[rossberg]

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.

[ghost]

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?