On 08/08/2025 4:28 PM, Steven Schveighoffer wrote:
> Not calling destructors at the end of the scope that a variable is declared in is a recipe for disaster.
> 
> For example:
> 
> ```d
> {
>     auto conn = lockConnection();
>     arr.map!(val => conn.send(val)).each; // allocates `conn` into a closure, because reasons.
> }
> 
> {
>     auto conn2 = lockConnection(); // if conn.dtor not run, then this is a deadlock.
> }
> ```
> 
> The better option is to not make arbitrary decisions that affect semantics of RAII.

Doing this is also a disaster.

Inject any copy into heap memory, into any position before an expression/statement. This may be done in another function that accepts it by-ref.

```d
__gshared Connection global;
	...
	global = conn;
	...
```

I.e.

```d
{
    auto conn = lockConnection();
    global = conn;
    arr.map!(val => conn.send(val)).each; // allocates `conn` into
a closure, because reasons.
}

{
    auto conn2 = lockConnection(); // if conn.dtor not run, then
this is a deadlock.
}
```

Note: while I am using a global, any heap memory will exhibit this behavior.

Depending upon how the struct is implemented you will get one of these behaviors:

1. Do nothing. Heap variable is both locked and unlocked depending upon the call stack, and depending upon implementation this may never be able to be used.

2. Ownership transfer (unique). Later operations will fail, but won't look like it should.

3. Disable copying and rely on return value optimization. The assignment will fail, but you won't be able to put it into stack memory that isn't by-ref. Acceptable solution.

4. Detect copy and unlock. Highly error prone at runtime, I've had this issue with my error types.

The only solution as a library author I can recommend is to disable copying. As a user, I would hate this due to past experience anything that enables error at runtime behavior from compiling.

But there is a fifth option, which is what I am proposing.

5. Disable going into heap memory. This gets you all of 3, but also allows you to copy it around within the stack, including into pointers. Ideally we'd also have escape analysis to guarantee going down only and treat it as a borrow to prevent multiple locking.

I do not like playing whack-a-mole on symptoms of a problem. And this issue for closures appears to be exactly that, a symptom of a much bigger problem.

Worth noting that doing nothing is equivalent to what you are proposing in the above example. All you've done is closed one hole in a sieve.