Here is my current concept of this beast:
The next installment of this is: how does assignment and conversion
work? Presumably, it starts with:
- there is a null-discarding conversion from T? to T! (this is a
narrowing conversion)
- there is a nullability-injecting conversion from T! t
On Thu, May 12, 2022 at 5:22 AM Brian Goetz wrote:
> - there is a nullability-injecting conversion from T! to T? (this is a
> widening conversion)
>
I think we'd expect full subtyping here, right? It needs to work for
covariant arrays, covariant returns, type argument bounds, etc.
> and the
On Thu, May 12, 2022 at 5:22 AM Brian Goetz
wrote:
- there is a nullability-injecting conversion from T! to T? (this
is a widening conversion)
I think we'd expect full subtyping here, right? It needs to work for
covariant arrays, covariant returns, type argument bounds, etc.
The
> On May 11, 2022, at 7:45 PM, Kevin Bourrillion wrote:
>
> * `String!` indicates "an actual string" (I don't like to say "a non-null
> string" because *null is not a string!*)
The thread talks around this later, but... what do I get initially if I declare
a field/array component of type 'Stri
* Exclamation fatigue would be very real, so assume there is some way to make
`!` the default for some scope
+1
Yes, I think it's a dead end to expect users to sprinkle '!' everywhere they
don't want nulls—this is usually the informal default in common programming
practice, so we need som
I don't see the conflict. I'm saying, yeah, there *will* be exclamation
fatigue until a feature comes along eventually to relieve it. (In the worst
case, that's `public null-marked class...`; in the best case it's just
`language-level 22;` or what have you.) But I still think it's the right
thing t
