On 12 Aug 2026 17:53, Ville Voutilainen wrote:
> On Wed, 12 Aug 2026 at 17:51, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>>>> Three relatively-concrete use cases come to mind:
>>>>> 1) poisoning a variable after it's been moved from
>>>>> 2) poisoning a task graph after it's been launched (which in Senders
>>>>> is also a move, but elsewhere might not be)
>>>>> 3) poisoning a task completion after its result has been received
>>>>
>>>> None of these require a permanent ban of the name.
>>>
>>> What do you mean by "permanent ban of the name"?
>>>
>>> It's poisoned within a scope. Once that scope exits, there is no remaining
>>> permaban.
>>
>> I'm not sure the scope of effect of redacting was precisely defined, but
>> in any case, my point is that the above use cases do not require any
>> name ban at all.
>
> Well, considering that the objects are not to be destroyed immediately
> when the namebanning scope
> begins, how do you suggest to do those cases?

My preference would be to "undeclare" those variables, i.e. make their
names not reserved after the respective objects and available for new
declarations. Undeclaring would not affect object lifetimes, only the
name binding.

Note that if a code attempts to reference a variable that has been
"undeclared", it will get a compile time error, same as with
"redacting". The difference is that the name remains available for
reuse, and the compiler doesn't have to track the name in any special way.