Need stronger rationale for not using span<byte>

[akrzemi1]

The "Span reflex" article criticizes two "reflex" opinions:

1. Using std::span<std::byte> for representing single buffers
2. Using std::span<std::span<std::byte>> for representing ranges of buffers.

While I agree with the criticism of #2, the criticism of #1 looks insufficiently founded in the context of Capy.

In Capy, we have a concrete type const_buffer with the following contract:

1. On one side, there is a set of factory functions that make a const_buffer form any recognizable range of trivially-copyable structures (including char).
2. On the other side, there are framework functions, that knowhow to convert a const_buffer to an iovec or WSABUF.

It looks like using std::span<const std::byte> instead of const_buffer (or making const_buffer an alias for std::span<const std::byte>.

It is true that std::byte unnecessarily gives provision to do byte-shifting operations, but who cares, when the only thing the users do with this type is to create it via capy::make_buffer and pass it to framework functions, which will now how to translate to iovec or WSABUF.

And the benefit of using std::span<const std::byte> is not having to introduce another type that the users have to learn.

Having a distinct type to indicate a minimally narrower contract makes sense in general, but is inconsistent with other decisions in Capy: all async operations return std::tuple<std::error_code, ...> even though there are special rules and relationships that apply to tuple elements.

The choice to introduce a new type would be clearer if const_buffer offered implicit conversions from every known sequence of trivially-copyable elements (what capy::make_buffer currently does), but this is not the case.

[akrzemi1]

Ok, it looks to me like Capy has an undocumented contract for all its buffer types (those qualifying as ConstBufferSequence or MutableBufferSequence) that copying them does not affect the addresses of the individual contiguous storage spaces. Even if the buffer-sequence type is copied 100 times, we are sure that we will write the bytes to the exact location that the user expects them.

The advantage of const_buffer over span<byte> is that it can provide this guarantee via preventing the conversion from things like vector<byte>.

So, the reason for introducuing const_buffer is the "no dangerous implicit conversions" guarantee.

[akrzemi1]

ASIO states this "stable address" guarantee for buffers explicitly: https://www.boost.org/doc/libs/1_92_0/doc/html/boost_asio/reference/ConstBufferSequence.html