Nullable type in generic method - dart

Question

I'm learning Dart, and I'd like to have a method similar to let in Kotlin.
I'd like to use it as:
var variable = ...;// nullable type, for example MyClass?
var test1 = let(variable, (it) => 'non null: ${it.safeAccess()}');
// test1 type is String?
var test2 = let(variable, (it) => 'non null: ${it.safeAccess()}', or: () => 'Default value');
// test2 type is String since either way we return a String
In this example, the variable is a nullable instance of MyClass and the output is a nullable String if no fallback is provided, or a non-null String if a non-null fallback is provided.
Here's the prototype I have written:
typedef O LetCallback<I, O>(I value);
typedef O OrCallback<O>();
O let<I, O>(I? value, LetCallback<I, O> cb, {OrCallback<O>? or}) {
if (value != null) {
return cb(value);
}
if (or != null) {
return or();
}
if (null is O) {
return null;
}
throw Exception("Please provide a default non-null value");
}
Dart complains I can't return null, but I don't understand why it's illegal. I had expected this (in explicit syntax):
var variable = ...;// nullable type, for example MyClass?
var test1 = let<MyClass, String?>(variable, (it) => 'non null: ${it.safeAccess()}');
// I=MyClass, O=String?
var test2 = let<MyClass, String>(variable, (it) => 'non null: ${it.safeAccess()}', or: () => 'Default value');
// I=MyClass, O=String
In my expectation, the compiler would infer the type O as either String? or String, so that return null is legal only if O is nullable.
It seems that using the generic syntax, the types referenced are always non-nullable. Is that so? Is it a limitation of the language? Is it possible to write what I want to achieve, or am I forced to have two implementations? (like let and letNotNull for example)
edit: after writing this, I tried the two implementations route. Here's what I have written:
typedef O LetCallback<I, O>(I value);
typedef O OrCallback<O>();
O letNonNull<I, O>(I? value, LetCallback<I, O> cb, OrCallback<O> or) {
if (value != null) {
return cb(value);
}
return or();
}
O? let<I, O>(I? value, LetCallback<I, O> cb, {OrCallback<O>? or}) {
if (value != null) {
return cb(value);
}
if (or != null) {
return or();
}
}
For some reason, this is legal:
var test = letNonNull(null, (it) => "whatever", () => null)
I had expected that the () => null callback would be a compiler error, since O can't be null (as per my initial observation: I can't return null).
It seems like the null-safety is not fully enforced.
edit2: it seems it's legal only if the type is inferred. E.g.:
letNonNull(null, (it) => "bogus", () => null); // legal
letNonNull<String, String>(null, (it) => "bogus", () => null); // illegal
I had hoped that the inferred types would be non-null...

Answer 1

You can't return null because O can, potentially, be bound to a non-nullable type.
Type variables are not "always non-nullable", but they are always potentially non-nullable. What you return from a function with return type O must be valid for all possible bindings of O, even when it's bound to non-nullable types. Or when it's bound to Never. That means that the only type that can possibly be valid to return is O itself, and null does not have type O.
If you want to always be able to return null, you must make the return type of let be O?. That makes it always nullable, even when O itself is not nullable.
In that case, I'd restrict O to be non-nullable by giving it a bound of extends Object.
The alternative, as you then do, is to return null if null is a valid return value, and throw if it's not (and thereby avoid having to return anything, since you have nothing to return), but your approach doesn't work with the type system.
Try changing
if (null is O) {
return null;
}
to
O? nullReturn = null;
if (nullReturn is O) {
return nullReturn;
}
As stated above, the only type you can return is O, so you want the value null to have type O. You can either do if (null is O) return null as O; (or even just return null as O; and rely on the TypeError from the cast istead of throwing yourself), or you can use type promotion like this example to avoid the extra as.
You probably also want to restrict I to be non-nullable using a bound, and then use I? for the argument to let, but not to cb. That ensures that the inferred I type is always non-nullable.
O let<I extends Object, O>(
I? value,
O Function(I) cb,
{O Function()? or}) {
if (value != null) {
return cb(value);
}
if (or != null) {
return or();
}
O? returnNull = null;
if (returnNull is O) {
return returnNull;
}
throw ArgumentError.value(null, "or",
"Please provide a default non-null value");
}
The letNotNull would also need to put a bound on the type variables:
O letNonNull<I extends Object, O>(
I? value, O Function(I) cb, O Function() or) {
if (value != null) {
return cb(value);
}
return or();
}
The reason
var test = letNonNull(null, (it) => "whatever", () => null)
is valid is that it infers letNotNull<Object, String?>, and
letNonNull<String, String>(null, (it) => "bogus", () => null); // illegal
is invalid because the type for O is not nullable.
The type system doesn't known how that or function argument is going to be used, it just checks that its a proper subtype of the O Function() parameter type for the actual value of O that is supplied.
The type checking of the function body ensures it can only be used in positions where the result is acceptable. That's the type checking which disallowed returning null above because that check has to work for all types that O can be bound to.
I'd consider defining the let operation as an extension method instead, because then it does type inference on the value first, before looking at the callback. Something like:
extension Let<T extends Object> on T? {
R let<R>(R Function(T) callback, {R Function()? or}) {
var self = this;
if (self != null) return callback(self);
if (or != null) return or();
R? nullReturn = null;
if (nullReturn is R) return nullReturn;
throw ArgumentError.notNull("or");
}
}

Answer 2

Just
return null as <The type you want>