Why use a DFA instead of DIP1000?

[Richard (Rikki) Andrew Cattermole]

On 13/09/2025 11:06 PM, Dennis wrote:
> On Saturday, 13 September 2025 at 02:39:40 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Paraphrased, why should we use a DFA engine instead of DIP1000?
>>
>> (...)
>>
>> Afterwards, I came up with an example, where DIP1000 will error:
> 
> Thanks for providing the example, it's a great discussion starter.
> 
> Like I said yesterday, it's not that I don't "know what data flow 
> analysis is all about" - when you have a solution, you can come up with 
> problems it solves, sure.
> 
> I was mostly curious what real world code made you believe that more 
> advanced DFA is necessary for useful scope pointer analysis. There's 
> many problems with DIP1000, but no issue was ever opened requesting 
> scope checks to be disabled in dead code. As far as I'm aware, [users 
> expect dead code to be type checked by the frontend as usual](https:// 
> forum.dlang.org/post/hullwyrnmgcaoghaqbux at forum.dlang.org).

That isn't my interpretation.

The code you linked would have been removed by a backend optimizer. It 
is dead code. It exists to get effects from the frontend (poorly), due 
to lacking language capabilities to archive the results needed.

DFA engines, for the purposes of linting like this thread is about, 
should focus on what code could actually run at runtime.

The fact that D is not architectured to be able to stop these false 
positives is an intended bug in our design. Not all PL's work like this 
the ML family certainly don't. They tie very advanced analysis engines 
including DFA into their type system.

Just because people don't understand that this is possible, doesn't mean 
it hasn't been an issue. I see it as a case that people don't know what 
they don't know. So they don't complain. This is a hole that the C 
family relies upon having due to historical reasons and so hasn't 
reached common knowledge.