Why use a DFA instead of DIP1000?

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Sat Sep 13 15:41:33 UTC 2025


On 13/09/2025 10:19 PM, kdevel wrote:
> On Saturday, 13 September 2025 at 02:39:40 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> [...]
>> Afterwards, I came up with an example, where DIP1000 will error:
>>
>> ```d
>> int* ptr;
>>
>> void func(bool b, scope int* p) @safe {
>>   assert(!b);
>>
>>   if (b) {
>>     ptr = p; // Error: scope variable `p` assigned to global variable 
>> `ptr`
>>   }
>> }
>> ```
>>
>> This is clearly a false positive; that branch could never run!
> 
> What about "release" mode? And what about that code:

What assert lowers to is irrelevant as far as a frontend DFA is 
concerned. It runs before that is taken into account.

> ```d
> void main ()
> {
>     assert (0);
> 
>     string s = "x";
>     s [0] = 'y';
> }
> ```
> 
> Is "Error: cannot modify `immutable` expression `s[0]`" a false 
> positive, too?

Yes actually.

Not all languages, and some in the ML line should have the ability to 
not process anything after the assert statement. They apply DFA into the 
type system to varying degrees. We don't.

For halt, we may have the ability to kill it off eventually. However we 
can't cull non-halt asserts, as we are not tieing our semantic analysis 
to a DFA engine. It is too late to change that.

Note: a halt assert is: assert(0)


More information about the Digitalmars-d mailing list