Smells like chatgpt

On Wed, 17 Sept 2025, 19: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
>