On 11/12/2025 10:22, Simon Schröder wrote:
>
>
> On Thu, Dec 11, 2025 at 9:48 AM David Brown <david.brown_at_[hidden]
> <mailto: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]
> <mailto: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.

Nor was I, until I tried it and then googled about it. So even if this
whole discussion leads nowhere, at least you and I have both learned
something :-)

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

I think the use of "override" in the first case should be optional. In
some cases, you would not want it - it is a little unnatural, as you are
not yet overriding anything. But for this kind of repeated pattern code
where you want the pattern to be clear and be able to change things
around easily, but the differences in each repetition are too big to
make refactoring the common code a good idea, then it is very nice to be
able to have "override" on the first case too. Swapping case 1 and 2
here is then just a movement of lines, not a movement then a change of
two lines.


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

Then we lose two things. First, there is nothing to indicate why we are
allowed to redeclare "x" here - it's just "const auto x" like normal.
And secondly, we are putting the "override" on exactly the part that is
/not/ overridden - it should then be "shadowed x" or something.

Maybe if the appearance of self-initialisation is bad, the
initialisation should be omitted altogether in the source?

 override const auto x;

> 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

Ideally the lifetime of "y" would end if "x" is a copy (and therefore it
could be handled as a move), while it would be extended if "x" is a
reference.

There's a big risk of feature-creep here. If the code would be clearer
with additional names, or by splitting a big function into parts, then
it would not be a good thing to add additional possibilities.

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

It would be consistent, yes, but would it be clear? I'd argue that
overriding x with a void type casts x into the void, destroying it. But
just overriding it doesn't make sense to me.