I don't see any major issue with the idea, but going through all these
standardization steps is a very big hammer for what seems to be the
very small problem of having to call gcount() after an I/O operation
separately.

It's not even like you're proposing functionality that was previously
difficult or impossible to obtain, so the value here is low enough to
where it's probably not worth the time and effort.

I personally also consider <iostream> to be defunct, ancient gunk
similar to <regex> at this point. It's really questionable whether we
want to spend time on improving it. There are many people who don't
see it the way I do though.

On Wed, 17 Sept 2025 at 20:40, Jerome Saint-Martin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals