On Thu, 18 Sept 2025 at 22:08, Lénárd Szolnoki <cpp_at_[hidden]>
wrote:

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


If they call streambuf::underflow and that throws an exception, they'll set
badbit. See [istream.unformatted].



> and you can't differentiate
> whether the read ended because of EOF or some IO error.
>

On EOF istream::read sets failbit|eofbit, and I don't think it sets eofbit
for any other conditions.

On EOF streambuf::in_avail() calls streambuf::showmanyc() which returns -1
and that makes istream::readsome set eofbit.



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