Provide support for "safe" and "simple" binary I/O in the GSL

[dmitrykobets-msft]

What are the editors' views on the GSL user issue Provide a "safe" and "simple" way for binary I/O · Issue #1104 · microsoft/GSL (github.com)?. The Microsoft GSL implementation always follows the interfaces defined by the Core Guidelines, but in this case the user is asking about interfaces not-yet specified in these guidelines, hence me forwarding the question here.

Some thoughts:

For the proposed solution of creating read and write overloads, can we simply create overloads for << and >> for gsl::span<char>?

// Sample implementation for read
std::istream& operator>>(std::istream& i, gsl::span<char> s)
{
    i.read(s.data(), s.size());
    return i;
}

These overloads would align with ES.2: Prefer suitable abstractions to direct use of language features, which encourages the use of >> and << over the messier read and write interfaces.

Note that the current gsl::span policy is to match the existing interface of std::span, except for bounds checking. The existing implementation of std::span does not have overloads for >> nor <<.

Regarding the points on byte buffers represented as gsl::span<gsl::byte>, it seems like buffers of std::byte were never intended to be used with the iostream library?

• c++ - How to use new std::byte type in places where old-style unsigned char is needed? - Stack Overflow
• c++ - How to use something like std::basic_istream - Stack Overflow
• there was a proposal to extend iostream support for std::byte, but that got abandoned: P2146 Modern std::byte stream IO for C++ · Issue #860 · cplusplus/papers (github.com)

So are the user's suggestions regarding byte buffers simply something the Core Guidelines do not intend to support?

[jdgarciauc3m]

Reading and writing a span<char> is not enough as we still would get the issue of ow to transform any type T into a gsl::span<char>.

The ultimate goal should be to allow binary I/O without needing to make use of reinterpret_cast.

[hsutter]

Editors call: Our current policy is that GSL's gsl::span follows the std::span interface exactly plus adds the ability to guarantee bounds checking. We are trying to avoid adding more convenience functions, but we recognize that we already have GSL span-aware copy function. We will keep this issue open for now and see if we can suggest WG 21 add bounds-safe span-compatible overloads for the standard library's (ptr, length) parameters.