“unset” is a somewhat decent/intuitive name for that feature if you take
suggestion.


Sent from Gmail Mobile

On Thu, Aug 13, 2026 at 13:49 Simon Schröder via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> > On Aug 12, 2026, at 4:21 PM, Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > On Wed, 12 Aug 2026 at 17:05, Tiago Freire via Std-Proposals
> > <std-proposals_at_[hidden]> 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_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>