On Thu, Dec 11, 2025 at 9:48 AM David Brown <david.brown_at_[hidden]>
wrote:

>
>
> On 10/12/2025 21:13, Simon Schröder via Std-Proposals wrote:
> >
> >
> >> 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) :
>
> The name-independent identifier (if that is the correct term?) _ won't
> work here for two reasons :
>
> auto _ = get_next();
> if (_) do_something1(*_);
>
> auto _ = get_next();
> if (_) do_something2(*_);
>
> The first reason is technical - while it's fine to re-declare "auto _ ="
> as often as you want, trying to use _ in the second "if (_) ..." fails
> as "_" has been defined multiple times and is ambiguous.
>

This is such a new feature, I wasn't aware that the second use is ambiguous.

>
> override auto value = get_next();
> if (value) do_something1(*value);
>
> override auto value = get_next();
> if (value) do_something2(*value);
>
> I do like using 'override' for this (especially as 'override' is the
correct term for shadowing a variable compared to 'overwrite'). However, I
don't particularly like to declare the variable as 'override' on the first
use (because it doesn't override anything at this point, yet). To be
consistent in the use of keywords (but certainly not in the use of the
meaning), the first declaration of the variable should be 'virtual' (just
kidding).

>
>
> >> 3. Const-locking identifiers (redeclaration without undecl) :
> >>
>
> Borrowing from point 1, I'd suggest :
>
> override const auto x = x;
>
Still, this looks like self-initialization. It would be challenging to put
this exception into the syntax. Maybe we could juggle the keyword around
and get:
const auto x = override x; // override in this context specifies that the
'x' on the right hand side is from a previous declaration
A generalization of this would be to also allow
const auto x = override y; // end the lifetime/visibility of y and change
the name to x
Basically, this is kind of the same as the 'undecl' keyword, but it returns
something that is assignable. Maybe this would have to mean that 'override'
makes the variable an r-value and to extend its lifetime we would actually
have to use a reference:
const auto &x = override x;
while
const auto x = override x;
would copy the variable. In both cases the name of the variable is free to
be used again in the same scope.

>
> You could even handle point 2 with :
>
> override void x;
>
> To be consistent with my use of 'override', it would be sufficient to just
write
override x;
This would make 'x' an r-value and because nobody extends its lifetime, it
would be destroyed.