[RFC] Throwing an exception with null pointers

[Richard (Rikki) Andrew Cattermole]

On 17/04/2025 1:41 AM, Derek Fawcus wrote:
> On Wednesday, 16 April 2025 at 08:49:39 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 16/04/2025 8:18 PM, Atila Neves wrote:
>>
>>> * Use a nullable/option type.
>>
>> While valid to box pointers, we would then need to disallow them in 
>> business logic functions.
> 
> I'm not sure what you have in mind, what I have in mind is something 
> like this:
> 
>    https://discourse.llvm.org/t/rfc-nullability-qualifiers/35672
> https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html
> 
> The checks here are performed in a distinct SA tool, not in the main 
> compiler.  However it catches the main erroneous cases - first two 
> listed checks of second link:

``clang --analyze -Xanalyzer -analyzer-output=text``

"While it’s somewhat exceptional for us to introduce new type qualifiers 
that don’t produce semantically distinct types, we feel that this is the 
only plausible design and implementation strategy for this feature: 
pushing nullability qualifiers into the type system semantically would 
cause significant changes to the language (e.g., overloading, partial 
specialization) and break ABI (due to name mangling) that would 
drastically reduce the number of potential users, and we feel that 
Clang’s support for maintaining type sugar throughout semantic analysis 
is generally good enough [6] to get the benefits of nullability 
annotations in our tools."

Its available straight from clang, it annotates variables and is part of 
the type system, but also isn't effecting symbol lookup or 
introspection. Its part of the frontend, not backend.

Exactly what I want also.

I'm swearing right now, I knew we were 20 years behind, I didn't realize 
that they are one stones throw away from the end game. We can't get 
ahead of them at this point.

The attributes are different to what I want in D however. For D I want 
us to solve all of type state analysis not just nullability.

>> If a pointer p has a nullable annotation and no explicit null check or 
>> assert, we should warn in the following cases:
>>
>> -    p gets implicitly converted into nonnull pointer, for example, we 
>> are passing it to a function that takes a nonnull parameter.
>>
>> -    p gets dereferenced
> 
> Given how individual variable / fields have to be annotated, it probably 
> does not need complete DFA, but only function local analysis for loads/ 
> stores/compares.

Fields no, it'll be hell if we were to start annotating them, Walter 
balked at that idea ages ago and he was right to.

I want stuff like this to work, without needing annotation:

```d
bool isNull(int* ptr) => ptr is null;

int* ptr;

if (!isNull(ptr))
	int v = *ptr; // ok
else
	int v = *ptr; // error

```

No annotations when things are not virtual or for the default case 
complex (such as backwards goto's, that needs a full CFG as part of DFA).

```d
void main() {
	func(new int); // ok
	func(null); // error
}

void func(/*?nonnull*/ int* ptr) {
	int v = *ptr;
}
```