Create an issue

[gmbegi89]

.....

[eernstg]

The syntax Object? denotes a top type that has no special treatment (unlike void and dynamic). The language specification (the proposed update to include null safety can be seen at dart-lang/language#2605) does not specify that there is a class (let's call it Any) which is a superclass of both Null and Object, and which would essentially be identical to the meaning of Object?, but I'm pushing for that outcome.

Anyway, we don't have that yet.

This means that there is no shared supertype of Null and Object which is identified with a class, and hence we can't say that the members of Null and the members of Object are inherited from anything. This is handled by simply claiming that those two classes have exactly the same members with exactly the same signature, and implying that the analyzer/compiler are aware of this fact. This yields the behavior we need during type checking etc.

The way this situation is described in the DartDoc documentation of the classes Object and Null is a bit confusing, but we can't really describe it in a simple and obvious way until we have agreed on a specific way to specify it.

Hence, I think the best way to proceed is to maintain that the language specification needs to specify this in a consistent and readable/non-surprising manner, and then we'll update the DartDoc.

[gmbegi89]

Here is the Null class code:

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

  external int get hashCode;

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

There is no == operator, but the following expression is valid.

if(null == variableName) {}

The analyser does not generate an error because the == operator is undefined on the Null type.

It doesn't stop you from writing programs, but it's still pretty weird.

[eernstg]

You can't rely on the source code in platform libraries. Many of those declarations (and certainly Null) are known by the analyzer and compilers in the sense that they are being compiled to something which can be arbitrarily different from the standard semantics of the source code. For example, a missing superclass is always Object, but we still get false if we evaluate null is Object.

The fact that we can invoke == on null is actually a funny exception, because evaluation of e1 == e2 is specified to special case null (as the receiver and also as an argument), which means that we will actually never call == on the null object, and null will never be passed as the actual argument. Oh, and web compilers are actually violating that property, because they compile this special treatment of the null object into every operator == method, as far as I know. It's turtles all the way down. ;-)

This is not going to go away, the platform libraries will inevitably introduce certain declared names whose semantics cannot be expressed in the language itself.

[gmbegi89]

Very often reading the source code can be clearer than the documentation, for this reason I hope that such an exception only applies to some special cases that are mentioned in the documentation somewhere. I note that the documentation in dart is quite good.

[eernstg]

Thanks for the kind words! - good documentation is certainly important.

It's not easy to give precise promises about which parts of the platform source code is "magical" (that is, the tool chain "knows" about specific declarations and gives them special treatment), but the 'sdk' directory contains about 216542 lines of code, which would be an upper bound. A lower bound could be any platform code which is dealing with types mentioned in the language specification (like int, bool, ..., Function, Type, and a few more). In any case, these primitive elements of the language (that is, anything which is Dart but can't be written in Dart) should be specified in the language specification documents. This is the language specification itself, https://spec.dart.dev/DartLangSpecDraft.pdf, plus a number of feature specifications dealing with the most recent features, here. The latter will be integrated into the former over time, but there will probably always be a number of language features which must be looked up in feature specifications because they haven't yet been integrated into the language specification.