Based on discussions in wasi-http/#8, we should consider a return-value optimization that avoids calling realloc by instead allowing the core wasm caller to supply a (buffer, length) i32 pair as a param. From my perspective, the main questions to consider are:
- For this to be useful, the optimization needs to apply not just for
list/string return types but also result<string> and other nested cases. But how far should this go? In the limit, it could apply to any use of list/string that's not nested inside a list, but that's probably too far.
- If the return value is a dynamically-sized
list/string which needs more bytes than given, should it just fall back to calling realloc and can the caller then be expected to observe this case by noting that the returned pointer is not the same as the given one?
- Is the speedup worth adding the special case?