Lasse R.H. Nielsen

> The example of a nullable but required parameter is imo a very valid use of `null` and should be a pattern that is still allowed. There are two problems...

If we allow subclasses of `Null`, and reify `ArgumentNotPassed` as a user-visible value, then we just push the problem further down. You can then *call* a function with an explicit...

> Does it mean all values with a default have to be nullable? Without the optional feature mentioned above, yes. That feature would allow you to write it as `{String...

> This has a consequence for code size. You have two conditions for the default value to be selected - when the argument is omitted and when the argument is...

One related idea to having multiple `null`s, instead of allowing users to write their own class extending `Null`, would be to have *typed* `null`s with a reified type. (Like the...

I'm slightly worried about the "view class"/"extension struct" syntax looking *too much* like class syntax, even though it really isn't a class. The `implements InterfaceName` syntax is particularly worrisome, because...

A boxing view is really just a wrapper with implicit forwarding. It's a class, it creates objects. It's not just a view. We can make it as struct instead, in...

I think my main issue here is that I don't understand the motivation for `implements` on extension structs. In classes `implements` provides four things: * Interface member signatures which can...

Another (possibly different) way to say the same thing: When a thing *implements* an interface, I expect to be able to cast it to that interface and get the implementation...

What @Levi-Lesches says. The problem is not the covariance, it's the inference. A `List` instance *can* be used anywhere a `List` instance is *expected*. Not safely, if you use the...