Do we need this generally throughout Blink, or is this just for Mojo interop?

If you expose a new feature to the web that accepts a BufferSource [1], the C++ binding for this sort of thing will be a blink::DOMArrayPiece. Depending on what you're going to do, you will probably need to pass that object over mojo.  So, it could be fixed with a way to serialize the DOMArrayPiece (without a copy if possible).  WDYT?

[1]https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/bluetooth/BluetoothRemoteGATTCharacteristic.idl

There are some complexities, and I'm not sure even whether this is doable.

* Our allocator distinguishes backing buffer for containers from regular
  allocations; also Oilpan allocations are totally different
* Expansion/shrinking? Realloc?

Why do you need to use Vector here? If you don't expand/shrink/update elements,
(theoretically) you don't have to use Vectors, since a raw pointer to the backing
buffer should be usually sufficient.

It sounds like we really just need Mojo support here. If we could typemap DOMArrayPiece to array<uint8_t>, I think that would solve this problem.

There are two problems with typemapping DOMArrayPiece to array<uint8_t>:
1. Typemaps map from a mojo type to a C++ type, so array<uint8_t> couldn't map to both WTF::Vector<uint8_t> and WTF::ArrayPiece at the same time.
2. Typemaps only map structs, unions and enums.

What is possible today is wrapping the array in a mojom struct:
struct Uint8ArrayWrapper {
  array<uint8> data;
};
typemapping that to a C++ struct:
struct Uint8ArrayWrapper {
  ArrayPiece* data;
};
with traits:
struct StructTraits<blink::mojom::Uint8ArrayWrapperDataView, blink::Uint8ArrayWrapper> {
  ConstCArray data(const Uint8ArrayWrapper& wrapper) {
    return ConstCArray(wrapper.data.byteLength(), wrapper.data.bytes());
}

This has some problems. Uint8ArrayWrapper is not reasonably receivable in the blink variant; StructTraits that create an ArrayPiece seems pretty terrible. Further, it's another wrapper.

Fixing this nicely probably requires decoupling the send and receive interfaces. That is, the send interface could accept anything that looks like an array (via ArrayTraits), but the receive side probably just wants a vector.

No action in close to 12 months, closing as obsolete.

Please re-open if you think it's still valid.