> On Aug 12, 2026, at 4:21 PM, Ville Voutilainen via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>
> On Wed, 12 Aug 2026 at 17:05, Tiago Freire via Std-Proposals
> <std-proposals@lists.isocpp.org> wrote:
>>
>> For me I would mostly be interested in the const case.
>> Example in an awkward initialization scenario, where a variable should be const (for const hygiene) but can't because of conditions.
>> But I can also see full erasure being useful in the case of scopes locks if you need them to exist but should not be messed with unless by trivial behavior when going out of scope.
>> Although I have to admit that the full erasure has little applications.
>
> Thanks, good point,
>
> 4) poisoning a variable after a construction-laterassignment pair, so
> it can't be const, and can't be declared unnameable,
> but should be unnameable after it has been both created and
> post-creation set up to guard a scope

I thought the solution to this was immediately invoked lambdas. In this way the variable can be marked const. All the non-const logic is moved into the lambda. And for ease of use (and because it is immediately invoked) we can just capture everything by reference. Maybe this style doesn’t look the nicest, but it does the trick.
> --
> Std-Proposals mailing list
> Std-Proposals@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals