Should Object methods be callable on nullable types?

[leafpetersen]

In NNBD code, is it valid to call methods from Object on nullable types?

int? i = null;
print(i.hashCode);

[leafpetersen]

Note that if not, you're not able to call Object methods on generic parameters that are not known to be non-nullable.

Also, I'm pretty sure we want to allow string interpolation to interpolate null values. So we'd have:

int? i = null;
print(i.toString()); // Error
print("$i"); // Ok

[eernstg]

There's an "under the radar rule" that a receiver whose static type is a union type supports access to members that are shared by all summands of that union type. With that, we'd say "yes".

[munificent]

If we answer "no" to this, then null really isn't an object (lowercase), for any useful definition of the term.

I believe the answer should be "yes". It's useful in practice, makes interpolation consistent with toString(), and lets you use null in maps and sets without needing weird special case handling.

It ain't broke now, so let's not "fix" it.

[matanlurey]

Drive-by comment:

Making Object's methods on Object? not callable will really hurt usability. For example:

class V {
  final String? name;
  const V(this.name);
  int get hashCode => name.hashCode;
  bool operator==(Object o) => o is V && name == o.name;
}

Both .hashCode and .== need to exist on a nullable type or this code is now invalid :-/

[leafpetersen]

Decided: yes, they can. @leafpetersen to write this up.

[gbaldeck]

So, playing devil's advocate here, if you have the following code in Flutter:

String _initalValueForTextFormField() { //Notice return type is String not String? so the return value should not be nullable
	int? initialvalue = SomeService.getInitialValue();
	return initialvalue.toString(); //issue in question on this line
}

Shouldn't the return statement above give an error so that the end user doesn't see null in the TextFormField? The error message may be something like:

initialvalue could be null so use the !! operator or check to make sure its not null

I used Kotlin's not-null assertion operator (!!) there, not saying you guys will decide on the same thing.

So valid code would end up being this:

String _initalValueForTextFormField() { 
	int? initialvalue = SomeService.getInitialValue();
	return initialvalue!!.toString(); // added the !! operator
}

Or this:

String _initalValueForTextFormField() { 
	int? initialvalue = SomeService.getInitialValue();
	return initialvalue?.toString() ?? "It was null!"; //added null check
}

[gbaldeck]

There's an "under the radar rule" that a receiver whose static type is a union type supports access to members that are shared by all summands of that union type. With that, we'd say "yes".

@eernstg Doesn't this go against what we are trying to achieve with nullable types? Say we have a custom class C that is unioned with null like below:

C? item = C();

And say that C? can use all the methods and properties that C has without having to use the .? operator, assert not-null operator (!! in kotlin), or do a null check, like this:

item.methodOnC()

Then what is the point of having the nullable types at all? Perhaps I'm not interpreting your statement correctly so please let me know if I'm not.

[munificent]

Shouldn't the return statement above give an error so that the end user doesn't see null in the TextFormField?

If we assume the return type of toString() is String and not String?, then, no, the code is fine. toString() won't return null, regardless of what you call it on. Calling toString() on null doesn't return null, it returns the four-letter string "null".

And say that C? can use all the methods and properties that C has without having to use the

That's not what he's saying. "shared by all summands" means every branch of the union has to have a member before you can access it, including the Null branch. Since Null has very few members (just toString(), hashCode, etc.), then a nullable type effectively filters out all methods except those that are available on Object. Those are exactly the methods you can call on null safely, so it does what you want.

[gbaldeck]

If we assume the return type of toString() is String and not String?, then, no, the code is fine. toString() won't return null, regardless of what you call it on. Calling toString() on null doesn't return null, it returns the four-letter string "null".

Right, I understand it returns the four letter word "null". Which is what I am arguing should not be allowed. If you look at the valid code blocks I posted, the first one throws an NPE because of the !! operator and the second one never returns the four letter word "null". It either returns the initalvalue string or returns "It was null!".

So while in theory, sure, letting null have the same functions as Object is fine, since in the example I posted the four-letter string "null" is technically not null. But in practice that example would end up returning string "null" to the user. That defeats one of the purposes of having nullable types in my opinion. When would you ever want the user to see the string "null"?

What I'm suggesting is that at the return statement the programmer is given some sort of warning, error, etc. saying "Hey, this value could be null. Either mark it as a possible NPE or do a null check."

That's not what he's saying. "shared by all summands" means every branch of the union has to have a member before you can access it, including the Null branch. Since Null has very few members (just toString(), hashCode, etc.), then a nullable type effectively filters out all methods except those that are available on Object. Those are exactly the methods you can call on null safely, so it does what you want.

Ah yes. Thank you for the explanation. Haven't had discrete math in almost a decade so I need reminders from time to time.

[leafpetersen]

There are definitely examples of places where one might prefer not to silently be allowed to call Object methods on null, even though they are in fact present. But in thinking through examples, there also seemed to be many more places where it would be really painful not to be able to do so. If you have a nullable type, then you often (though not always) intend for null to be a meaningful object there, usually indicating absence. Think json, or a property that is not always present. If printing out such an object, or computing its hash code, requires special casing null on each nullable field, it rapidly gets really ugly. Note that you'd have to do this in generic code that wasn't restricted to non-nullable types:

class A<T> { 
  T x;
  String toString() {
    String xAsString = x?.toString() ?? "null";  
    return "A{x = $xAsString}";
  }

Overall, this felt like very awkward for fairly limited benefit. Yes, we'd help you catch the cases where you really didn't want to accidentally print out null, but this doesn't seem, to me at least, to justify the cost.

FWIW, Kotlin seems to make the same choice - it allows calling Object methods on nullable types.

[gbaldeck]

I see your point, and I'm probably not thinking through all the cases where my suggestion would be a problem (I'm definitely not). Two language teams, probably the Swift team too, have come to the same conclusion so it must be the way to go.

[leafpetersen]

Interestingly, as best I can tell Swift objects have no common base class with a common set of methods, and Any and AnyObject don't seem to have any methods that I could find (admittedly on limited amount of poking, but this makes sense given their purpose). So it may simply not come up there - any Swift experts around that can confirm or deny this?