Proposal: Add a version of std::istream::read() that returns the number of bytes read

Current behavior: std::istream::read(char* buffer, std::streamsize count) returns a reference to the stream (std::istream&). To get the actual number of bytes read, one must call gcount() separately:
  ifs.read(buf, size);
  auto nread = ifs.gcount();

Suggested improvement: Introduce an overload or utility function that returns the number of bytes read directly:
std::streamsize read_and_count(char* buffer, std::streamsize count);
Why this matters:

    ✅ Improved clarity and conciseness: Reading data and getting the byte count is a common pattern. Wrapping this into a single expression reduces boilerplate and cognitive load.

    🧠 No added risk: Internally, this would simply call read() and return gcount(). It
doesn’t alter stream behavior or semantics.

    🧰 Easy to implement: This is syntactic sugar, not a fundamental change to the I/O model.

    🧓 Backward-compatible: The existing API remains untouched. Developers who prefer chaining stream operations can continue as before.

    🌍 Language consistency: Many other languages (C, Python, Rust, Go) return the number of bytes read directly. C++ could offer this ergonomic option without compromising its design philosophy.

Conclusion: This isn’t about reinventing the wheel — it’s about smoothing the ride. For a language that prides itself on performance and expressiveness, offering a more intuitive way to read data seems like a natural evolution. And for those who fear change: this is additive, not disruptive.

Naming note: While read_and_count offers clarity and aligns with traditional STL naming conventions, an alternative like readncount could be considered for its brevity and modern feel. It echoes naming patterns found in lower-level APIs (recvfrom, strncpy) and may appeal to developers seeking concise, expressive interfaces. This suggestion is purely stylistic and intended to spark discussion around ergonomic naming.