On Fri, 6 Jun 2025 at 14:16, Peter Bindels via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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.
>


New attributes [[🤨]] and [[😱]] to tell people not to use certain
functions.