C++ Logo

std-proposals

Advanced search

Re: [std-proposals] [Draft] Typed and Safer Stream API for C++

From: Phil Bouchard <boost_at_[hidden]>
Date: Sun, 7 Sep 2025 10:38:58 -0400
You may want to read the "[std-proposals] regex over istreams" thread as
I suggested something similar earlier this year.



Thanks,

-Phil


On 9/7/25 09:09, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] [Draft] Typed and Safer Stream API for C++
>
> A reason it was done as it was done, could be that the mode to open a
> file is externally visible by the operating system and I think can
> have influence over whether you are allowed to open the file.
>
> The added control could have been more important than avoiding seeming
> contradictions.
>
> The mode is optional and can probably be seen as 'expert mode'?
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jerome Saint-Martin via Std-Proposals
> <std-proposals_at_[hidden]>
> *Gesendet:* So 07.09.2025 15:12
> *Betreff:* Re: [std-proposals] [Draft] Typed and Safer Stream API
> for C++
> *An:* Ville Voutilainen <ville.voutilainen_at_[hidden]>;
> *CC:* Jerome Saint-Martin <jerome.saint-martin_at_[hidden]>;
> std-proposals <std-proposals_at_[hidden]>;
> "Thanks for the reply. My point is precisely that the API allows a
> combination like |ifstream| with |ios::out| to compile — even
> though the semantics of the type make that combination
> nonsensical. That’s what I meant by 'illogical mode combinations'.
> Yes, you can extract the |filebuf| and do tricks, but that’s
> beside the point. The issue is that the type and the mode should
> be coherent by design, and ideally, such contradictions should be
> caught at compile-time. Allowing them to compile silently is what
> I find confusing and misleading
> ------------------------------------------------------------------------
> *De:* Ville Voutilainen <ville.voutilainen_at_[hidden]>
> *Envoyé:* Dimanche 07 septembre 2025 14:54
> *À:* Jerome Saint-Martin <jerome.saint-martin_at_[hidden]>
> *Cc:* std-proposals_at_[hidden]
> <std-proposals_at_[hidden]>; Jonathan Wakely
> <cxx_at_[hidden]>; Matthieu Terrier <mterrier_at_[hidden]>;
> Caroline Pierron <caroline.pierron_at_[hidden]>; Madelenat,
> Christophe <christophe.madelenat_at_[hidden]>
> *Objet:* Re: [std-proposals] [Draft] Typed and Safer Stream API
> for C++
> On Sun, 7 Sept 2025 at 15:47, Jerome Saint-Martin
> <jerome.saint-martin_at_[hidden]> wrote:
> >
> > The point is precisely that allowing std::ios::out as a flag
> when constructing an ifstream is misleading. It compiles, which
> implies that writing might be possible — but it doesn’t work,
> because ifstream is inherently a read-only stream. That’s what I
> meant by 'illogical mode combinations': the API permits a flag
> that contradicts the semantics of the type.
> > Ideally, such contradictions should be caught at compile-time,
> or at least discouraged by the design. Otherwise, developers are
> left with silent failures and confusing behavior.
>
> Well, it doesn't seem like a silent failure or confusing behavior that
> when you attempt to write to an ifstream, that doesn't compile.
>
> You can also extract the filebuf from an ifstream and write to the
> file via the filebuf, if the ifstream was opened in read-write mode.
>
> I think it might be a clearer expression of your intended design to
> have an input stream that refuses to open a file in write mode?
> And further, that the open mode must be a constant, so no
> runtime-selection of the open mode, and therefore the aforementioned
> refusal happens at compile-time?
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>
-- 
Email Signature
Fornux Logo <https://www.fornux.com/>  
*Phil Bouchard*  LinkedIn Icon 
<https://www.linkedin.com/in/phil-bouchard-5723a910/>
Founder & CEO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
720 Oliver Ave, San Diego, CA, 92109
The Best Predictable C++ Memory Manager 
<https://static.fornux.com/c-superset/> Le message ci-dessus, ainsi que 
les documents l'accompagnant, sont destinés uniquement aux personnes 
identifiées et peuvent contenir des informations privilégiées, 
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce 
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named 
recipients only and may contain privileged or confidential information 
which is not to be disclosed. If you received this communication by 
mistake please destroy all copies.

Received on 2025-09-07 14:39:02