Why use a DFA instead of DIP1000?

[Richard (Rikki) Andrew Cattermole]

On 17/09/2025 3:52 AM, Dennis wrote:
> On Tuesday, 16 September 2025 at 14:21:07 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Here are some code similar to what I've sent Walter over the past year 
>> for what I want to work by default for escape analysis in D.
> 
> You gave 4 code snippets. 1 and 2 already compile as expected, 3 already 
> errors as expected if you add `@safe`, and 4 has no defined expected 
> behavior. None of these have a source linking them to an existing D 
> user / code base.
> 
> To reiterate, the question is:

As expected.

These examples show true positives. The problem is eliminating perceived 
false positives but keeping the intended true positives.

>> Can you think of any more realistic examples where DFA allows you to 
>> infer safety where DIP1000 is currently limited?
> 
> As long as you keep dancing around it, I'm going to assume the answer is 
> 'no'.

Okay fine.
Bugzilla is down, so I can't look through the WONTFIX's and I'm not 
going to go hunting on the N.G. learn forum.

I can spot: https://github.com/dlang/dmd/issues/19679
You tried to fix it and haven't in the past. With a DFA for the 
infrastructure, that wouldn't be possible to have existed.

Another example from you for the above: 
https://github.com/dlang/dmd/issues/18113

Here is a ticket, with a comment from you showing why DIP1000 needs to 
be lint level attribution. 
https://github.com/dlang/dmd/issues/20302#issuecomment-2542028404
If it isn't you break things like the .di generator since it runs before 
semantic.

It also results in issues like: https://github.com/dlang/dmd/issues/19853

Another example where DIP1000 loses track of lifetimes: 
https://github.com/dlang/dmd/issues/18153
Pretty nasty.
To fix that you would need to keep track of a stack of lifetimes, with 
full knowledge of the variables in a function signature. All things a 
DFA would be good at.

An example where appropriate CFG processing with a DFA would allow this 
to not error: https://github.com/dlang/dmd/issues/19659
Sadly my fast DFA isn't able to model it so the statement walker marks 
the variable as unmodellable which prevents the false positive.
To model this across function boundaries, we need to add an escape set 
in the CFG of blockexit and on the function declaration.