Perhaps this syntax would be interesting:

mutable const a = …
final a;

Using those existing keywords would have a meaning here that a is const after n writes or after manual final

Cheers, Filip

> Wiadomość napisana przez Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> w dniu 10 gru 2025, o godz. 21:14:
>
> 
>
>> On Dec 10, 2025, at 9:46 AM, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> 1. Copy-and-paste code (redeclaration without undecl) :
> This variant I don’t really like. It would be too easy to accidentally shadow a variable. If I have working code and I accidentally redeclare a variable (possibly with the same type) right between the declaration of the old variable and the previously last use of the variable, I will break that code without a compiler error. In my opinion it is a good thing to have compiler errors when you try to do something stupid. (Maybe we could allow shadowing without undecl and then unshadow using undecl. Anyway, it would be much better if you’d had to be explicit about shadowing, e.g. with an attribute [[shadow]]. Nothing accidental about that.) BTW, if you want a variable you can shadow, use _.
>>
>> 2. Explicitly ending the lifetime of a variable and making it unusable:
>>
> Other languages (e.g. Rust) use the ‘keyword’ ‘drop’ for this. I’m not sure if ‘drop’ will collide with common variable names (or more likely with function names). ‘undecl’ certainly looks like it is not yet used in any C++ code. As has been replied already: std::optional already allows to end the lifetime of a variable early (but without the added “benefit” of being able to reuse its name (if it’s not the same type)).
>>
>> 3. Const-locking identifiers (redeclaration without undecl) :
>>
> This is a nice idea I could get behind.
>>
>> auto x = get_x();
>> change_x(&x);
>> const auto x = x;
>> change_x(&x); // Compile-time error
>>
> Currently syntax like the line
> const auto x = x;
> would first declare a variable ‘x’ and then assign it to itself. We should have some other syntax for this feature. It is currently already possible to write this kind of buggy code if ‘x’ comes from an outer scope. There is no reason for this to behave differently if we shadow an ‘x’ from the same scope. And certainly someone is “relying” on this bug and we’d break someone’s code if we fix this.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals