On Fri, Jun 6, 2025 at 10:23 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Tue, 3 Jun 2025, 19:29 Simon Schröder via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>>
>> On Jun 1, 2025, at 10:32 AM, Thomas Krogh Lohse via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>> I’d love to hear your thoughts:
>> * Do you see value in defining a "safe-by-default" C++ subset with
>> opt-in unsafe features?
>>
>>
>> “Safe-by-default” will not work. C++ always tries to be backwards
>> compatible and old (currently correct) code might not compile with your
>> feature on.
>>
>
> Narrowing conversions became ill formed. Some lambda captures have been
> deprecated (and are not ill formed? I don't remember). Asymmetric equality
> operators became ill formed.
>
> I don't think "old code must compile" is always such a hard line.
>

We need something between "fully available" and "deprecated". When we have
things that 90% of people know are bad and are not using, we cannot
consider deprecating it because breaking 10% of code, which affects 90% of
users, is way beyond acceptable.

Having such a thing prevents us from proliferating the use of the outdated
constructs, which leads to a future in which we will have much less use of
it, and where we can reasonably at some point say "this once common
construct is now actually deprecated". It is also a thing that allows us to
try out "what if we did remove XYZ" and seeing the results of it, before
making it into the standard.