Dart API page for class `Null` contradicts itself

[sgrekhov]

I'm not sure that this is a right place for filling this issue but I didn't find the better one.

Please see https://api.dart.dev/dart-core/Null-class.html.

The Null class is the only class which does not implement Object.

But at the same time, the members of this class are marked as override and inherited. This contradicts the statement above.

[eernstg]

I'd prefer that we introduce a new sealed top class (Any) and specify that Null extends or implements Any, and Object extends or implements Any, and no other class is or can be a direct subtype of Any (such that it is sound to say that if an object isn't null then it is guaranteed to have type Object).

With that, the description in any context including https://api.dart.dev/dart-core/Null-class.html can avoid the weasel talk about the situation. For example, how come e.toString() can possibly be type correct if e has a nullable type? We don't otherwise consider two separately declared members to have any relationship, unless they are both overriding the same member of some shared superinterface.

(See, for example, #53314 (comment)).

[lrhn]

It all depends on perspective.

One could claim that the Null class extends Object, but does not implement it.
That probably raises more questions than it answers.

Or we can introduce the secret Any type that implements both, and which is referenced as Object?, but then why are the same members of Object not also marked as override and inherited?

It's basically a hack that shows through, and a legacy from back when Null did implement Object.
I think the docs should just not have those markers. Or it should show them for Object too.

[RohitSaily]

Within the Dart language, the SDK defines Null as

@pragma("vm:entry-point")
final class Null {
  factory Null._uninstantiable() {
    throw UnsupportedError('class Null cannot be instantiated');
  }

  external int get hashCode;

  /// Returns the string `"null"`.
  String toString() => "null";
}

Normally, classes automatically inherit from Object but Null is an exception. Since it doesn't explicitly show signs of inheritance or conformance to Object, I believe continuing to simply state it as an exception to that inheritance rule would be a direct solution. Therefore, I agree with the idea that override and inherited should be removed from the documentation.

---

@eernstg with the current rules of the language your idea for a top type makes sense to me as it would make typing consistently follow the rules and not require special cases. I cannot find any issues or proposals regarding this manner, have you considered starting a discussion centred around that specifically?

[eernstg]

make typing consistently follow the rules and not require special cases

Right, that's the point. When the model has been adjusted to be as simple and consistent as possible then the override relationships and lots of other things have a clear resolution, and the documentation should just explain what it is. Some class doesn't have a superclass, so there must be an exception to the rule "every class has a superclass" that otherwise holds everywhere. However, we don't need two exceptions.

The SDK definition of the class Null doesn't actually matter: Everything and anything in system libraries can be given special treatment by the analyzer and the compilers (the system libraries are "known" by the tools, so they can break the rules for, e.g., class Null). This means that the declaration of Null doesn't have to have Object as its superclass even though the rules about class declarations stipulate that an omitted extends clause means extends Object.

So we can decide on a particular model (e.g., the top type denoted by Object? is also a class Any, etc), and then the tools just have to avoid contradicting it, and if they can work with any given declaration of Null in a system library then that's fine, and it isn't required to look exactly as we'd expect according to the model.

[RohitSaily]

I see, my thinking is limited to the language as I haven't interacted with any formal model or specifications relating to Dart, but I think I understand it better now.

I am not sure if it is already, but if it isn't, would it make sense to formalize void as a defined top type which the Any would be a subtype of. Systems would continue to prevent the user from using void values or void type-checks as they currently do. void would just be an empty type (no declarations, inheritance, etc) making it continue to function as some sort of destructive type erasure.

Also, if the Never type were put into this picture, then I see the type hierarchy like this.

graph TD;
void-->Any;
void-->Never;
Any-->Object;
Any-->Null;
Object-->...

Loading

[FMorschel]

Actually, from my understanding, Never is assignable to anything. It would be the bottom most class even after the user-written classes.

[RohitSaily]

Yes, I have just skimmed through various sources and you are correct.

I find the design choice confusing.

import 'dart:io';

void main()
{    final (a, b)=getLengths();
     print(a*a*b*b*exit(0));
}

Why not keep it separate to enforce computations that act like sinks to be explicitly separated.

import 'dart:io';

void main()
{    final (a, b)=getLengths();
     print(a*a*b*b);
     exit(0);
}

Are there some kind of benefits to having Never as the bottom type?

[eernstg]

@RohitSaily wrote:

would it make sense to formalize void as ... [in the graph]

I think the current subtype relationships around void would have to be preserved. It would simply be too breaking to consider void to be a separate type (e.g., such that Object? would be a subtype of void, but not vice versa).

(Note that my proposal about introducing a top type which is a class Any doesn't break anything, it just makes the specified subtype structure conform more directly to the behavior we already have.)

Currently, void is a top type (that is, every other type is a subtype of void, including the other top types). So all the top types are "sitting in the same spot" with respect to the subtype relation, and that's significant when it comes to the run-time behavior.

Different top types are given special treatment during static analysis. For example, a dynamic receiver has its member access operations (such as method calls) checked at run time rather than at compile time. Another example is that when an expression of type void yields a result (that is, it doesn't throw), this result should be ignored. But at run time the top types are just the type that includes every object whatsoever.

On the other hand, Never is a bottom type. We don't just have one, e.g., a type variable X extends Never is also a bottom type. In practice, though, it's fair to say that Never is the bottom type. That is, it is a subtype of every other type. With respect to the included set of objects, it is a subset of the included set of objects of every other type because it's the empty set.

That yields the following subtyping structure:

graph BT;
  Object --> Top["Any ==<br>void ==<br>dynamic ==<br>Object?"]
  Null --> Top;
  others["..."] --> Object;
  Never --> others;
  Never --> Null;

Loading

Are there some kind of benefits to having Never as the bottom type?

Here are a couple of examples:

void foo<X>([List<X> xs = <Never>[]]) {
  ...
}

Never die() {
  throw "Something went wrong!";
}

int doSomething(num n) {
  switch (n) {
    case 0: return 1;
    case 1: return 2;
    default: die();
  }
}

This illustrates that a List<Never> can be used where a List<T> is expected, for any T whatsoever. You couldn't use <X>[] as the default value, because X is not a constant type expression (with different invocations of foo there may be different types bound to X). However, if you leave out the type argument then it will actually be inferred as Never in the case where the list literal must be a constant expression.

The other example is the function die. It returns Never in order to inform the caller that it will never (pun intended!) return an object. That is, it will throw, or it will just loop forever, but it won't return anything. Another way to say the same thing is that if it returns something then that thing will belong to the empty set (consequently, it doesn't return anything).

If you change the return type of die to void (which is allowed) then the analyzer/compiler will tell you to put some extra code at the end of the body of doSomething, because it looks like we might reach that point and return to the caller without specifying which int to return, which is a compile-time error.

So if you have a function whose whole job is to create a suitable object and then throw it then you'll probably be happier if it has return type Never than anything else.

[RohitSaily]

Thank you for taking the time to explain this.

I understand now that Never must remain as a bottom type in order
to not break code. For example, Never can be assigned to any type
parameter, even if the parameter is constrained to be a subtype of
any type, therefore removing it as a bottom type would break code
relying on such ability.

When experimenting with the top types in the following code

const dynamic dynamicObject=null;
const void voidObject=null;
const Object? anyObject=null;

void dynamicToVoid()=>
	dynamicObject;
Object? dynamicToAny()=>
	dynamicObject;

dynamic voidToDynamic()=>
	voidObject;
Object? voidToAny()=>
	voidObject;

dynamic anyToDynamic()=>
	anyObject;
void anyToVoid()=>
	anyObject;

An error is reported for the function voidToAny because it tries
to return a void object when Any, i.e. Object?, is expected.

So would not the following be the case?

graph BT;
Any-->top[dynamic==void]
Object-->Any
Null-->Any
everythingElse[...]-->Object
Never-->everythingElse
Never-->Null

Loading

I'm not sure how Object? is formalized, but as I understand, it
can be interpreted as a type union of Object and Null. So we can
consider that some sort of composite/derived type. Since they have
the common supertype Any, the Any interface e.g. hashCode,
runtimeType, etc. is guaranteed to be accessible for such type
unions. This makes it consistent with how code currently works for
nullable types.

[eernstg]

The type void (and the type dynamic) are actually not proper supertypes of Object? (and they wouldn't be proper supertypes of Any), they are all "the same type" when it comes to subtyping. The reason why voidToAny is an error is that void is given special treatment during static analysis. (T is a proper supertype of S when T is a supertype of S, and S is not a supertype of T.)

const void voidObject = null;
Object? voidToAny() => voidObject /*compile-time error*/;

The type void is given special treatment in several ways, but in this case it's about using the value of an expression of type void.

We have an allowlist of rules about where an expression of type void can occur here. For example, the first 4 rules are as follows (starting with each rule in a bullet point, followed by some rationale in italic):

• In an ⟨expressionStatement⟩ e;, e may have type void. The value of e is discarded.
• In the initialization and increment expressions of a for-loop, for (e1; e2; e3) ..., e1 may have type void, and each of the expressions in the expression list e3 may have type void. The values of e1 and e3 are discarded.
• In a type cast e as T, e may have type void. Developers thus obtain the ability to override the constraints on usages of values with static type void. This means that it is not enforced that such values are discarded, but they can only be used when the wish to do so has been indicated explicitly.
• In a parenthesized expression (e), e may have type void. Note that (e) itself has type void, which implies that it must occur in some context where it is not an error to have it.
• (...several more rules...)

This basically means that an expression of type void can occur in locations where the value is guaranteed to be discarded. There's a (deliberate) loophole: You can put (voidObject as Object?) anywhere you want. In that sense, as works as a kind of key which can unlock "the void object".

In the declaration of voidToAny, voidObject occurs as an expression whose value is returned, and that's not on the allowlist, so we get the error.

The rationale for this design is that void is a type which can be used to indicate that a given value is of no interest, and any use of this value is a mistake. It isn't a soundness violation, and there's nothing wrong with the object as such (usually, it's null), but if you think this object means something then you have probably misunderstood the entities that you are using in that expression.

For example print(print('Hello!')) makes no sense because the outer print is trying to print the value which is returned from the inner print, and print isn't intended to return anything of interest. You probably meant print('Hello!').

If you actually meant it then you can grant yourself the ability to do it: print(print('Hello!') as Object?), but we aren't going to let you do it without that extra circumstance of casting to Object? (or casting to whatever you want).

In contrast, the claimed subtype relationship (that is: "Any is a proper subtype of void and dynamic") is misleading. You can see this by forcing the assignment (using a cast), and seeing that there is no cast failure at run time:

const void voidObject = null;
Object? voidToAny() => voidObject as Object?;

void main() {
  var x = voidToAny(); // Does not throw.

  // Even better example that _only_ relies on the subtype relationships.
  var xs = <void>[] as List<Object?>; // Does not throw.
}

The cast as List<Object?> would definitely fail at run time if void had been a proper supertype of Object?.

I'm not sure how Object? is formalized,

The rules about subtyping have special cases for Object?, and all the normal rules about types of the form T? apply to Object? as well. In particular, Object and Null are subtypes of Object? because of the normal rules, and dynamic is a subtype of Object? because of a special top-type rule.

[RohitSaily]

That makes sense to me, I think I understand it much better now. Your original diagram with all the top-types at the same level is definitely the way to go.

I am left wondering if there are any restrictions by the fundamental rules governing the type system that prohibit us from saying Object? has declarations associated with it e.g. toString(), which is usable by all nullable types.

Also for another idea, can't it also be said that the nullable methods are extension methods on Object? (which is syntactic sugar for static functions)? e.g.

final class Object
{      /// Defines hashCode, ==, toString, etc.
}

final class Null
{      /// Also defines whatever is necessary e.g. hashCode, toString, etc.
}

extension Any on Object?
{     String toString()=>
            switch (this)
            {       Object o=>o.toString(),
                    Null n=>n.toString()
            };
}

There is the rule extension_declares_member_of_object, but isn't that just a static analyzer restriction? It states

Such a member can never be used because the member in Object is always found first.

But null is! Object, so wouldn't the member of Object be found iff the underlying reference was actually that of an Object and not null?

[eernstg]

if there are any restrictions by the fundamental rules governing the type system that prohibit us from saying Object? has declarations associated with it

It's just a weird exception: Members are introduced by member declarations, and they can occur in class declarations, mixin declarations, etc. In this case we claim that Object? introduces some members. How would that happen? Is there some kind of syntactic representation of these members somewhere?

The whole thing is much easier if we have this:

abstract class Any {
  dynamic noSuchMethod(Invocation _);
  String toString();
  int get hashCode;
  Type runtimeType;
  bool operator ==(Object _);
}

and then Object and Null get to implement those members in whatever way they please (which is exactly the same as today). With that, there's no special exception that allows us to call toString on an expression whose value could be null, and it could also be an instance of a subtype of Object (including Object itself, by the way). The point is that it is in any case an Any, and an Any has all of those members (and they must have an implementation because it's an object, so the run-time type is some concrete subclass of Any).

[RohitSaily]

The only thing I cannot convince myself is why an Any class declaration would be preferable over an extension Any on Object?. Since Null is not a subclass of Object, won't it resolve to calling the correct member? If that does not work I understand the need for a new and explicit top-type declaration.