A DFA that only works with a forward pass will generate a lot of complaints as people get baffled by the situations where it fails.

The forward pass attribute inference D has generates complaints and bug reports when it fails, because it does not handle cycles.

On 9/13/2025 8:42 PM, Richard (Rikki) Andrew Cattermole wrote:
> The linked code is not static if, its a regular if.

I know. I was trying to clarify the difference between regular if and static if.

On 15/09/2025 7:55 AM, Walter Bright wrote:
> A DFA that only works with a forward pass will generate a lot of complaints as people get baffled by the situations where it fails.
> 
> The forward pass attribute inference D has generates complaints and bug reports when it fails, because it does not handle cycles.

Oh I see where you're thinking.

Okay, consider the following reports, does any report (or lack thereof) suggest people are going to be baffled by it?

Relevant files (start.d for reports source code, out.txt for full log):

https://gist.github.com/rikkimax/652f96a33934bd8ae0a68fb849821385#file-start-d

```
start.d
testdfa\start.d(236): Error: Variable `ptr` was required to be non-null and has become null
    foreach (i; 0 .. 2)
    ^
testdfa\start.d(257): Error: Variable `ptr` was required to be non-null and has become null
    foreach (i; 0 .. 2)
    ^
testdfa\start.d(308): Error: Dereference on null variable `ptr`
        int v = *ptr; // error
                ^
testdfa\start.d(330): Error: Dereference on null variable `ptr`
        int v = *ptr; // error
                ^
testdfa\start.d(613): Error: Assert can be proven to be false
    assert(val); // Error: val is 0
           ^
testdfa\start.d(619): Error: Assert can be proven to be false
    assert(stack.length == 1); // Error: stack is null
                        ^
testdfa\start.d(673): Error: Dereference on null variable `ptr`
        return *ptr; // error could be null
               ^
testdfa\start.d(703): Error: Assert can be proven to be false
        assert(ptr !is null); // error
                   ^
extracted.d
```

Worth looking at extracted.d and the full log.

On 14/09/2025 7:58 AM, kdevel wrote:
> On Saturday, 13 September 2025 at 15:43:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> [...]
>>> I thought that the intent of the original code
>>>
>>> ```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`
>>>    }
>>> }
>>> ```
>>>
>>> was to show that there is some code-block
>>>
>>> ```d
>>>      ptr = p; // Error: scope variable `p` assigned to global variable `ptr`
>>> ```
>>>
>>> which is never executed regardless of the value of `b`.
>>
>> Half right.
>>
>> There is a code block that will never be executed, it is because of variable b's state is known to prevent that code block from execution.
> 
> Then it is dead code that should be manually removed? Isn't that the problem here? The compiler correctly complains about invalid code, this is not a false positive, even if that code is never executed.
> 
> If I want code not to be executed I comment it out or delete it.

In practice, when this is applied people don't complain about it.

https://github.com/dlang/dmd/issues/21859

Compiles with full D, but not -betterC (which does the extra check without the culling which is a bug).

```d
void func() nothrow {
    if (0) {
     	 throw new Exception("");  // Error: cannot use `throw` statements with -betterC
    }
}
```

When both DFA and Control Flow graph (CFG) processing is working correctly its a well loved compiler feature. You don't know its there unless something has gone wrong like in the above code.

When I learned how nothrow inference worked I was really impressed with how it was applying CFG analysis. I did not expect the frontend to be doing it.