Date: Sun, 7 Sep 2025 13:12:06 +0000
"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?
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?
Received on 2025-09-07 13:12:11