On 17/09/2025 20:26, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Wed, 17 Sept 2025, 19:57 Jan Schultke via Std-Proposals, <std-
> proposals_at_[hidden] <mailto: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.

My understanding is that read and readsome never set badbit, and you can't differentiate
whether the read ended because of EOF or some IO error.

fread/feof/ferror is a little bit better in this regard. But you typically want to
differentiate EINTR from other errors, and there is no portable ISO C way to do that.
AFAIK libstdc++ just silently continues on EINTR for fstreams.

Correct me if I'm wrong though, I'm not entirely confident in my understanding.

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