Escaping objects and what is escape analysis modelling anyway?

[Richard (Rikki) Andrew Cattermole]

On 28/07/2026 4:27 AM, Dukc wrote:
> On Saturday, 25 July 2026 at 14:52:30 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> An example of this is you can utilize conditionals to model 
>> relationships:
>>
>> ```d
>> int* returnCond(bool cond, int* obj)
>> {
>>     if (cond)
>>         return null;
>>     else
>>         return obj;
>> }
>> ```
>>
>> So this could have a graph that looks like:
>>
>> ```
>> [
>>     ( if (params[0] == true)
>>         return = null
>>     ),
>>     ( if (params[0] == false)
>>         return = params[1]
>>     )
>> ]
>> ```
> 
> Probably the compiler can't rely on this, other than for optimisations, 
> unless we'll also have attributes to specify this manually. Otherwise 
> `returnCond` couldn't be put to a `.di` file, nor could you type a 
> function pointer so that you could call it like this.
> 
>> Do the following functions have the same relationship between their 
>> function parameter and return value?
>>
>> ```d
>> int** rel1(int** param) => param;
>> int** rel2(ref int* param) => ¶m;
>> ```
>>
>> Yes and no.
>> A big part of the problem here is `rel2`, you can look at it and think 
>> oh I know it's got two cells, just like `rel1`!
>> And that is true as far as what you should have access to.
>> But its not; it's actually the same parameter as the first `rel1`, but 
>> you've specified that the first indirection is guaranteed to be non- 
>> null and should be ignored.
>> This gives you three cells, with the first being hidden to the user, 
>> and the second being automatically dereferenced.
>> That is storage of the parameter, pointer to `int*` that was passed 
>> in, and then the `int*` itself.
>>
>> Knowing this allows us to model function calls of functions like these 
>> and know that the assert will hold true during compilation
> 
> I'm afraid you have misanalysed this and might be basing your escape 
> analyser on sand.
> 
> If this was C++ you would be right, since calling a C++ function with a 
> `&` reference to null is undefined behaviour. However, the D spec 
> doesn't say so (nor could it, since it's allowed in `@safe`. Could in 
> principle be implementation-defined, though), and in fact a `ref` 
> variable residing at null will [not even crash](https://forum.dlang.org/ 
> post/flutpcacmrxoqmnshrrw at forum.dlang.org) if you don't use it anyhow. 
> It seems likely this is the intended behaviour, though I don't have a 
> confirmation.

I have implemented a null check to disallow it, in addition to the DFA's 
ability to catch such cases.
Currently needs maturing. But it is in master.

Nullability is something Walter hasn't placed much weight on solving due 
to MMU's, however this makes debugging harder and does limit D's use 
cases when it comes to application development for things like web 
development. There are requirements on recoverability that Walter 
doesn't agree with, but needs to be offered regardless.

Just because it has been allowed, doesn't mean that it is good code that 
should be accepted moving forward. In the case of derefencing null, it 
is never good code that should be accepted.