On Wed, 17 Sept 2025, 19:57 Jan Schultke via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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.
>

You don't have to call gcount though. istream::read always reads the full
count, unless it encounters EOF or an error. So generally you want to check
"was this successful?" and not "how many characters did it read, and was
that equal to the number I asked for?"

Returning the stream allows you to check for fail it or badbit, which tells
you whether the requested number of characters was read.


> 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.
>

It's a better API than is given credit for. Idiomatic iostream code is
very different to fread/fwrite code, but I find it much easier to write
correct code that handles errors properly.



> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>