C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Readncount Proposal

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Wed, 17 Sep 2025 22:05:59 +0000
X2

From: Std-Proposals <std-proposals-bounces_at_[hidden]ocpp.org> On Behalf Of Jonathan Wakely via Std-Proposals
Sent: Wednesday, September 17, 2025 21:15
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>
Subject: Re: [std-proposals] Readncount Proposal

Smells like chatgpt

On Wed, 17 Sept 2025, 19: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]ocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2025-09-17 22:06:08