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:
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);
✅ 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.