Perl uses the 'topic'
$_
as standard input/output variable.
-----Ursprüngliche Nachricht-----
Von: Connor Song via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 12.08.2026 14:13
Betreff: Re: [std-proposals] A new C++ keyword: forget
An: std-proposals@lists.isocpp.org;
CC: Connor Song <perdixky@gmail.com>;
Hi all,
I wonder whether
_could cover much of this use case without introducing a newredactconstruct.My intuition is that
_already communicates something close to:this object may need to exist, but its name is not intended to have a stable identity that later code should remember.
That seems especially relevant to the cases where
redactis useful only because the object must remain alive while direct access to it should effectively disappear.For example, consider a borrowing wrapper:
Socket _ = connect(); TlsConnection secure(_); // from here on, use only `secure` secure.send(data);The underlying
Socketstill has to remain alive becausesecureborrows it, so introducing an inner scope and destroying it early would be wrong.But giving it a normal name such as
rawalso advertises a stable access path which later code can accidentally use:Socket raw = connect(); TlsConnection secure(raw); raw.send(data); // accidentally bypasses TLSWith
_, the declaration itself already tells the reader that the underlying socket has no meaningful long-term name.I think this becomes more interesting if name-independent declarations named
_are allowed to rebind_within the same scope.Conceptually, I have in mind a rule along the lines of:
Multiple name-independent declarations named
_may inhabit the same scope. An id-expression_denotes the most recently preceding such declaration.There is one important additional rule I think would be needed:
The binding introduced by a new
_declaration becomes the current_only after its initializer has been evaluated.That would make pipelines possible:
auto _ = receive(); auto _ = decrypt(_); auto _ = authenticate(_); process(_);Here the
_indecrypt(_)refers to the result ofreceive(), while after that declaration completes,_refers to the result ofdecrypt().Likewise, the
_inauthenticate(_)refers to the decrypted value, and the new binding becomes current only after initialization is complete.In other words, this:
auto _ = parse(input); auto _ = validate(_); auto _ = normalize(_); consume(_);would naturally express a sequence in which each intermediate value is intentionally anonymous and only the latest stage matters.
Importantly, I would not want rebinding
_to end the lifetime of the previous object.For example:
Socket _ = connect(); TlsConnection secure(_); Widget _ = make_widget();the original
Socketobject must still remain alive for as long as normal C++ lifetime rules require, even though_now denotes theWidget.So this would affect name binding, not object lifetime.
That distinction seems useful to me:
a normal identifier gives an object a stable identity;
_gives an object only a temporary handle;introducing a new
_replaces that handle without destroying the previous object.This also seems preferable to
Socket raw = connect(); TlsConnection secure(raw); redact raw;because with
redact, the fact thatrawis intended to be temporary is only revealed later.With
Socket _ = connect();that intent is visible immediately at the declaration site.
So I wonder whether the problem is less about needing a way to revoke ordinary names, and more about making name-independent
_useful as an explicitly ephemeral binding.Best,
Connor-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals