Date: Sat, 06 Sep 2025 20:55:23 -0700
On Saturday, 6 September 2025 11:08:16 Pacific Daylight Time Jerome Saint-
Martin via Std-Proposals wrote:
> Thanks for your thoughtful response. I just wanted to clarify that my
> proposal was never intended to replace the existing API based on
> std::ios::openmode. I fully agree that dynamic composition of flags is
> essential and cannot be expressed at compile time — which is precisely why
> the old API must remain. What I’m suggesting is a parallel API, designed
> for the simpler, static cases where compile-time safety and readability are
> beneficial. Much like how std::span complements raw pointers without
> replacing them
I don't think that is correct. std::span, std::unique_ptr effectively do
replace raw pointers in most places. New API should use those and others
almost exclusively, not raw pointers. Raw pointers have their uses, but they
are restricted in a world where those higher concepts exist.
Yours isn't the case. The new and old APIs have the exact same use-case,
differing only on whether the decision is made at compile time or runtime. Both
must be taught so people would know to choose them. And since one of them
works for both cases (the old one), why would we need the new one?
Martin via Std-Proposals wrote:
> Thanks for your thoughtful response. I just wanted to clarify that my
> proposal was never intended to replace the existing API based on
> std::ios::openmode. I fully agree that dynamic composition of flags is
> essential and cannot be expressed at compile time — which is precisely why
> the old API must remain. What I’m suggesting is a parallel API, designed
> for the simpler, static cases where compile-time safety and readability are
> beneficial. Much like how std::span complements raw pointers without
> replacing them
I don't think that is correct. std::span, std::unique_ptr effectively do
replace raw pointers in most places. New API should use those and others
almost exclusively, not raw pointers. Raw pointers have their uses, but they
are restricted in a world where those higher concepts exist.
Yours isn't the case. The new and old APIs have the exact same use-case,
differing only on whether the decision is made at compile time or runtime. Both
must be taught so people would know to choose them. And since one of them
works for both cases (the old one), why would we need the new one?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-09-07 03:55:38