Should vector<string> be a usable buffer sequence without any copying involved?

[akrzemi1]

As per the title, should the user expect that std::vector<std::string> be satisfying concept MutableBufferSequence and usabe out-of-the-box with streams without any copying involved?

Currently it does not work, and the reasons is that const_buffer and mutable_buffer do not provide converting constructors that would make any suitable type be converted to them.

If the answer is "no", then there is no reason to keep the flexible concept MutableBufferSequence that allows types convertible to const_buffer and mutable_buffer, because it adds no value alone.

If the answer is "yes", then either the concept needs to change to include explicit conversions via make_buffer or const_buffer and mutable_buffer should get converting constructors.

[anarthal]

I'd say it should work. I find it more important with const buffers though, i.e. const vector<string> should be a ConstBufferSequence. I don't have a direct use case for it though.

[akrzemi1]

Now that I think about it, currently ConstBufferSequence has a property that the type represents a handle: it can be passed by value and this never triggers the cloning of the underlying storage. This would be compromised if we allowed vector<string> const&.

[anarthal]

Then say span<string>

[akrzemi1]

Sorry, going back to vector<string> const&. A similar question to answer is, when the algorithm receives a model of MutableBufferSequence, should it be allowed to to freely copy the parameter, and be sure that the storage for bytes stays at the same location?

[anarthal]

Hm. Looks reasonable I'd say. Specially after coroutine parameter lifetime traps.

[akrzemi1]

I just realized that the expectation/answer may be different for ConstBufferSequence than for MutableBufferSequence. For ConstBufferSequence an unexpected deep copy may be inefficient but correct. For MutableBufferSequence, filling a different storage that the user has no access to, is almost certainly a bug.