Prevent struct going into heap memory

[Richard (Rikki) Andrew Cattermole]

On 21/07/2025 2:47 PM, Paul Backus wrote:
> On Monday, 21 July 2025 at 02:10:09 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 21/07/2025 2:03 PM, Paul Backus wrote:
>>>     Problem is, some people believe it shouldn't. Hence this proposal to
>>>     give those that want that "reliability" control to make it so.
>>>
>>> If there are people who believe that (a) the struct instance should 
>>> be allocated with the GC, but (b) the GC should not be responsible 
>>> for its cleanup, then those people are wrong, plain and simple.
>>
>> Ah no, they don't like the GC introducing unreliability to the cleanup.
>> So they want to ban destructors in closures.
> 
> This seems like a totally self-inflicted problem. If they don't want to 
> rely on the GC for cleanup, nobody is forcing them to. D has plenty of 
> mechanisms for predictable lifetime management already.

The problem is closure creation isn't always predictable just from 
looking at your code.

Add to it, not having @localnogc and we don't have any guarantees to 
prevent this.

Yes I'm acknowledging that these are either bugs or perceived bugs.

>> Just disabling destructors doesn't give the predictability that you 
>> seek, there has to be more language checks than that.
> 
> What "checks" could we possibly introduce that would help with this?

See my original post.

Its because of transitory nature of structs with interaction with no 
guaranteed cleanup of pointers.

```d
struct Wrapper {
	RAII raii;
}

void func() @safe {
	Wrapper* wrapper = new Wrapper; // Error: Wrapper's destructor is 
@stackonly due to field raii.
}
```

If you want guaranteed cleanup the only way to make that happen is to 
get the struct on the stack where the compiler can see it. If you don't 
do this, you do not have the guarantee to begin with.