Unless I misunderstand your concern, I think we can get away with using
StringPiece in the call/dispatch interface but still using std::string for
intermediate storage in the event that we don't serialize right away. That
should eliminate as many copies as we can reasonably eliminate, right?

Thanks Ken.
Agreed with #1.

A few thoughts:
- If we would like to go down this direction, there seems no reason why this should be limited to base::StringPiece. Some custom types may have the same ownership problem and require different param/storage types as well. But that requires two StructTraits for serializing both the param/storage types.

- Mapping mojom string to base::StringPiece is convenient if passing a single string. But it is less so if the user has a std::vector<std::string> and wanty to pass into a mojo call accepting std::vector<base::StringPiece>.

Supporting separate param and storage types is also required for issue 700180.

In addition to base::StringPiece we also have base::span<T> which is a good replacement for std::vector<T> when T is a type where we can simply map the storage out of the message, such as uint8_t.

base::span<T> is a good adapter between various buffer types when ownership of the data is not needed. For example in the USB interface if Mojo methods took base::span<uint8_t> instead of std::vector<uint8_t> then in the renderer the ArrayBufferOrArrayBufferView could be passed directly to the transfer functions. On the browser process side the callbacks could be called with a net::IOBuffer (or base::RefCountedMemory). In both cases copying the buffer into an intermediate std::vector before message serialization could be avoided. Only on deserialization is a copy actually necessary.

Yeah, base::span<T> is useful sometimes. I created ReadOnlyBuffer mojom type and typemapped it to base::span<const uint8_t>:
https://cs.chromium.org/chromium/src/mojo/common/read_only_buffer.mojom?rcl=c58b56d6408886513e9f87a2bff2ea276d0c058d&l=10

I have used it in ipc.mojom to avoid copying at either side.

And there is array_traits_span.h that you could use when writing traits specializations:
https://cs.chromium.org/chromium/src/mojo/public/cpp/bindings/array_traits_span.h

ReadOnlyBuffer satisfies my desire for base::span. We could probably close this issue if we added ReadOnlyString and ReadOnlyString16 types as well. My only concern is that it is a bit odd to recommend against using built-in types.

It's also weird to reference a "ReadOnlyFoo" in mojom, in my opinion, just
to get subtly different typemapping behavior. I would rather we just
implement more granular typemapping controls so you can provide
context-sensitive type configurations.

i.e. so you can say mojom.Foo has different type representation for storage
vs transient passing.