Object Pascal, Memory Safety, the US Whitehouse and future programming

[440bx]

Alex, thank you for the thorough explanations.  I appreciate that.

[AlexK]

That said, I haven't given the problem enough thought to figure out if there is a solution in that case but, if there is one, it means more work for the compiler, consequently slower compilation.

The idea would be in creation of the static analyzer and leaving compiler fast and compatible.

The analyzer would depend on FPC source to get AST and conduct its analysis project-wise.
Modern languages maintain official analyzers that can verify code while typing, in current context. Compiler invocations become less often.
Analyzer's source code is meant to be approachable for everyone who grasped several concepts.

Analyzer can do escape analysis in functions and practically become "static garbage collector" providing guarantees closer to Rust level.
It could generate a human readable statistical report about memory safety of a project.

"Sound Nil Safety" by itself is a huge feature in a language, but it requires small addition to lexer and parser for "?", "!", "late".
And compatibility requirement with commercial Delphi may be off-putting for some probable contributors.

Well, static analyzer could validate code for null safety of existing unchanged syntax by applying rules of the usual defensive programming style - every reference can be nil. Validating all blocks that use pointers/references, etc.

[marcov]

I think the problem with the sound null type is that the primary nullable type, has many other more serious issues.

There are much less rules for pointer in FPC Pascal dialects, where pointers can point to any address in the system, not just allocations like in classic pascal.

[AlexK]

I think the problem with the sound null type is that the primary nullable type, has many other more serious issues.

This works without errors in Object Pascal.
NIL is cast to some class and instance method is called, on NIL object...

Code: Pascal  [Select][+][-]

1. type
2.   TX = class
3.     function Str: string;
4.   end;
5.  
6. function TX.Str: string;
7. begin
8.   if Self = nil then begin
9.     Result := 'nil'
10.   end else begin
11.     Result := 'not nil'
12.   end;
13. end;
14.  
15. begin
16.   Writeln(TX(nil).Str);
17. end.
18.  

Not properly documented, or maybe just a mention of this is located somewhere deep.
Method must NOT be virtual or dynamic.

It hints that there exist some default instance for each defined class.

[marcov]

Self is only needed for certain things like field access and virtual methods, which you don't do in that method, which is why it doesn't bomb.

However that self is or isn't used is not a guarantee, so this is illegal code. 

[AlexK]

so this is illegal code.

Maybe in some countries.
But the culprit is this line:

Code: Pascal  [Select][+][-]

1. Writeln(TX(nil).Str);

Go language thoroughly documents its NIL, use cases.
Free Pascal wiki page about NIL doesn't show this trick.

[AlexK]

Self is only needed for certain things like field access and virtual methods, which you don't do in that method, which is why it doesn't bomb.

However that self is or isn't used is not a guarantee, so this is illegal code.

Code: Pascal  [Select][+][-]

1. Writeln(SomeClass(nil).SomeMethod);

It's similar to C++.  Compiler sees a call to SomeMethod which is not virtual and inserts a direct call to the method passing it a NIL pointer as Self.
It copies C++ behavior, I suppose it probably comes historically from Borland.

Self can be NIL. That's why Object Pascal implements Free method like this:

Code: Pascal  [Select][+][-]

1. procedure TObject.Free;
2. begin
3.   if self<>nil then
4.     self.destroy;
5. end;

Any non-virtual method can be called with NIL pointer as Self, and programmers usually never check Self for Nil value.

For programmer that call is obviously wrong because of NIL literal, but compiler doesn't check it.

[AlexK]

I think the problem with the sound null type is that the primary nullable type, has many other more serious issues.

There are much less rules for pointer in FPC Pascal dialects, where pointers can point to any address in the system, not just allocations like in classic pascal.

quote: "primary nullable type, has many other more serious issues"...

In some cases NIL acts as an operator, or indicates special meaning for some types.

Code: Pascal  [Select][+][-]

1. // NIL sometimes is an operator.
2. var
3.         chk: array of boolean;
4.         msg: PChar;
5.         prc: TProcedure;
6. begin
7.         chk := nil; // clears dynamic array, acts like an operator
8.         msg := nil; // empty string, special meaning
9.         prc := nil; // procedural variable not referencing any procedure
10. end.
11. // And this is unreadable.

So, in Object Pascal with "Sound Nil Safety" non-NILable variable of string type would lose ability to represent empty string.
It would have required slightly more changes to the language than just lexer/parser with "?", "!", "late".

**********
But regarding this
quote: "There are much less rules for pointer in FPC Pascal dialects, where pointers can point to any address in the system, not just allocations like in classic pascal."
It shouldn't be a problem, references are too treated as typed pointers.

[Warfley]

In some cases NIL acts as an operator, or indicates special meaning for some types.

No nil is not an operator, it's a keyword representing a value, but the value it represents is dependent on the context. Basically in an assignment the left hand side of the assignment defines what value "nil" is going to take. So "nil" is outside the Pascal typesystem, it's not a single value with a fixed type, it's a class of different values for different contexts.

Personally I think that this is a really bad design decision. It's literally the only concept in Pascal where the right hand side of an expression is dependent on the left hand side, and kindof undermines the typesystem. It follows the same logic as null in C, which worked out so great that C actually changed that behavior and now has a type nullptr_t with only one value "null", and defined type conversions to other pointer types.

[gidesa]

Code: Pascal  [Select][+][-]

1. // NIL sometimes is an operator.
2. var
3.         chk: array of boolean;
4.         msg: PChar;
5.         prc: TProcedure;
6. begin
7.         chk := nil; // clears dynamic array, acts like an operator
8.         msg := nil; // empty string, special meaning
9.         prc := nil; // procedural variable not referencing any procedure
10. end.
11. // And this is unreadable.

Of course one could add to Pascal some functions as ClearArray(a), EmptyCString(s), UnassignProc(p), prohibiting the use of nil in that cases.
I see that many people think that nil is bad.
The typical argument against a Fpc "v 2025", with constrained nil, could be existing old/legacy code. No problem for apps, one has to modify them to comply, or use old compilers. The real problem is that same compiler and other utilities do heavy use of nil...

[AlexK]

In some cases NIL acts as an operator, or indicates special meaning for some types.

No nil is not an operator, it's a keyword representing a value, but the value it represents is dependent on the context. Basically in an assignment the left hand side of the assignment defines what value "nil" is going to take. So "nil" is outside the Pascal typesystem, it's not a single value with a fixed type, it's a class of different values for different contexts.

This model you described, is flawed, the part that "Nil is outside type system". Sound in "Sound Null Safety" refers to the Type System, it must be sound.
There's a graphic explanation using a type hierarchy tree where TObject is root at the top and Nil considered an automatic subtype of any defined type, hence can be assigned to any object variable.
All leaf types in that type tree(those without subclasses) point down to Nil, automatic subtype it is.

Imagine "Sound Nil Safety" is already in Object Pascal and not all variables can be Nil.
You'd realize that Nil was used as an operator or instead of possible methods/properties that weren't implemented in favor of Nil.

Nil assigned to a variable of managed type(refcounted) acts like a method or operator that decreases reference count.

[AlexK]

I see that many people think that nil is bad.
The typical argument against a Fpc "v 2025", with constrained nil, could be existing old/legacy code. No problem for apps, one has to modify them to comply, or use old compilers. The real problem is that same compiler and other utilities do heavy use of nil...

Important to emphasize that "Nil is bad" is only how Rust is implemented.(and functional langs)

"Sound Null Safety" considers Nil useful but gives full control to programmer and compiler that guarantees there'll be no unexpected runtime "NullPointerException"s.
It also prevents Nil from overloading/bloating, when you can't deduce easily by looking at code what Nil is supposed to mean for some particular type.

"Sound Null Safety" is the most novel concept-solution in languages/compilers, but fixes half-century problem that wasn't considered harmful.

[Khrys]

Nil assigned to a variable of managed type(refcounted) acts like a method or operator that decreases reference count.

Nil  is not special in that regard - it's the management operator itself that decrements the original value's reference count.
It's an untyped constant, plain and simple. And since untyped constants act like macros,  Nil  is essentially the same as C's  NULL  (also defined as a macro).

I agree with @Warfley. It's confusing that the same keyword may represent null values of wildly distinct types: raw pointers, class instances, class references, interfaces, long strings, dynamic arrays, procedural variables (references to methods contain two pointers even!)

[marcov]

But regarding this
quote: "There are much less rules for pointer in FPC Pascal dialects, where pointers can point to any address in the system, not just allocations like in classic pascal."
It shouldn't be a problem, references are too treated as typed pointers.

The point is that nil pointer exception is not the most dangerous exception in the system like those managed/safe languages that you mirror. It is dereferencing a stale pointer/reference.

[gidesa]

"Sound Null Safety" considers Nil useful but gives full control to programmer and compiler that guarantees there'll be no unexpected runtime "NullPointerException"s.

Good. But this implies that nil/null is considered of limited utility, a "dangerous, handle with care" concept.
Anyway, having more control would be surely nice. But  no one will rewrite compiler with controlled nil (and Lazarus, all libraries, etc.).