Should Object be nullable by default?

[leafpetersen]

This issue is to discuss the question of whether the Object type should be nullable by default when we enable NNBD types.

Arguments I've hard so far:

For:

• Since null supports all of the operations that are defined on Object, it works perfectly well anywhere an Object is expected.
• It's not clear what tangible benefit you get from being able to say that something can be any type, except Null.

Against:

• There is no way to express the type of a non-null object without this. So you can't write a generic class which requires only non-nullable type arguments. Does this matter?
• You won't get definite assignment warnings on variables of type Object.

cc @lrhn @munificent @eernstg

[kevmoo]

From an end-user perspective, having Object be "different" here would be a bit confusing.

As an experiment, JsonDecoder now is Converter<String, Object>. null is a totally valid output.

In a world without nullable Object, what would the 2nd type argument be?

[leafpetersen]

In a world without nullable Object, what would the 2nd type argument be?

Object?

[kevmoo]

Oh! So, Object would just be like Customer – that's what I hoped.

So put me in the against camp. 😄

[leafpetersen]

A minor concern that I have with making Object nullable is that if we have neither non-nullable Object nor T!, then there is no user visible type that we can ascribe to x in the following code if we promote:

foo(Object nullable) {
  if (nullable != null) {
    var x = nullable;  
  }
}

On the other hand, there is essentially no difference between Object? and Object! in terms of methods available on them, so it's not all that useful to know that x is non-nullable.

[eernstg]

My general preference is to let Object denote all objects other than the null object (that is, to make it non-null).

There is no way to express the type of a non-null object without this

Right, to me that's the main reason. But there's a technical as well as a conceptual side to it.

Technically, we'd otherwise need a special exception to even denote the set 'all objects other than the null object'. As mentioned, we'd use Object!, but that would already be a special exception (because ! is otherwise never used, or at least needed, on a statically resolved type).

Technically, we are also well positioned to claim that Object does not include the null object: Just like all other types today, they are implicitly subject to the transformation T --> T | Null almost everywhere. So the only breaking change would be that null is Object will now be false.

But, even more importantly, I think it is useful to support the concept of having an object "which is actually there", as opposed to the null object which is hardly ever used because it is useful in its own right, it is always used in order to indicate that "something else could be here, but it was omitted or it is not yet in place".

In contrast, I think it makes sense to be maximally permissive with dynamic and void, so they should be nullable (and I don't care if developers get less-than-optimal support for expressing dynamic!, not to mention void! ;-).

We might want to say that dynamic and Object then evaluate to different instances of Type, because they do not include the same set of instances any more, and that might be breaking. Not sure how dangerous that is, though...

[lrhn]

One user input is that it would be surprising if List<Object> (no "?" in there) could contain null.

For consistency, it would be nice if Object was non-nullable and Object? was nullable, just as for any other type (well, except Null which is the same type as Null?).

If we go that way, then we need to define what Null is if it's not a sub-class of Object.
We could just say that it's another class with no supertype, like Object and it has the same methods, and you can use those methods on nullable types.

Or, as Erik suggested, we could say that there exists a class which is represented by Object? and which has Object and Null as subclasses, and no superclass itself. It's the new top-object-type, and we just don't tell anyone its real name, so they have to refer to it as Object?, and it's what you get when you nullify Object. That requires some special-casing in the specification, but then some other things fall out automatically. I don't think it's distinguishable from the previous two-top-classes design from a user perspective, it's all about how to specify the behavior, and which things we get for free.

[eernstg]

I think we should have a class and a reified representation of that class corresponding to the top type, such that we have a simple story about why it is possible to say o.toString() etc. when o is "anything", including a function object and null. Evaluation of dynamic and void should also return a reification of the top type (although they are allowed to return 'dynamic' and 'void' from toString()).

It may look like an exception, but I think it's OK for Object? (if we allow that to be an expression, syntactically, otherwise it could certainly be the value of a type variable) to evaluate to a Type instance which represents the top type, rather than evaluating to the Type for Object in some wrapper that means | Null. We could also allow such non-normalized top type reifications to exist, and just insist that they compare equal to the plain top type according to ==, but I suspect that we would offer a better service to developers if we normalize eagerly.

With this firm notion of a top type, we can maintain a simple conceptual model about what it means to be an "object", and we also have the simple model that being an Object means being an "object" which is not the null object.

[leafpetersen]

Technically, we'd otherwise need a special exception to even denote the set 'all objects other than the null object'.

I think part of the question here is, why would we need this? I haven't really seen an argument for it yet.

[eernstg]

I think the notion of 'all objects other than the null object' is conceptually useful, because the null object is almost always used to indicate that something is not available (or not yet available), so we may wish to indicate that we won't encounter any "missing objects".

For instance, a Set like data structure could use this type as the bound on its type variable, indicating that it makes no sense for null to be a member of it.

If you buy the idea that it is useful, it seems more straightforward to me if Object denotes the non-null type and Object? is used to express the corresponding nullable type, rather than inverting it such that we must remember to use Object! respectively Object, just for that single type Object.

(And the special exception is that we wouldn't otherwise ever use ! on a compile-time resolved denotation of a type, and maybe we shouldn't even allow using it on anything other than a type variable, given that we could make it obviously and consistently useless on everything other than a type variable.)

[munificent]

I think the notion of 'all objects other than the null object' is conceptually useful,

But is it practically useful? I'm fairly confident a more practically useful type would be String+, which is the set of strings that are not empty (""). intz, the set of ints except for zero would be nice for preventing divide-by-zero errors. We don't have any plans to add either of those, so it feels weird to me to put a lot of effort into defining a new type for "Object minus this one special value" when we don't have any know use cases for it.

For instance, a Set like data structure could use this type as the bound on its type variable, indicating that it makes no sense for null to be a member of it.

But we wouldn't do that for Set because it is useful for users to define sets that may contain null. And if that's useful for Set, I don't see why that wouldn't be useful for other user-defined set-like classes.

One way to resolve this would be to go through the core libraries and see if we can find any places where we'd use Object-null. If we can't find any, it's probably not a well-motivated feature. If we can, then great, let's do it. :)

[lrhn]

In Dart, null is an object, because it's a value and all values are objects. If it is not an Object, then we have some notion of "object" that is different from is Object (and which would then be is Object?).

The only place where you would need Object instead of Object? is where null means something else than any other value. That is, where null means something. Say, Map<K,V>.operator[] which has return type V? and returns null on a non-entry and the entry value for an entry. If V is Object, then you can detect absence of an entry from that lookup. It might even make sense to force map values to always be non-nullable, so that assigning null as value for a key would remove the entry. This is what Expando does, and I think it's what we should have done from the start for maps and sets too (although I'd probably allow null as a map key, which feels odd if it can't be a value). It would be a breaking change to do it now, though.
(And it would break people who use maps as "sets of pairs" rather than actual maps).

I doubt there is any SDK code that we will actually change to use Object to not include null because it would be breaking, not because we don't want to or it wouldn't be useful. It's places where null already means absence, we could then prevent it from meaning something else.

I don't think making Object nullable will be an actual problem, as long as we have some other way to force a type argument to be non-nullable where possible, instead of just extends Object. There is no code that can accept Object instances that can't also handle null, because to all existing code null is an Object.

[leafpetersen]

This may be a little tied up with the discussion of optional parameters and default values. I think there's been at least one proposal to have foo({int x}) mean that x is a required parameter (since it is non-nullable). But I'm not entirely sure how that is intended to play out with generics. If we take this interpretation, and we want to be able to say that foo<T>({T x}) has a required named parameter x, then we may need to be able to say that T is a non-nullable type parameter, which requires some non-nullable top type.