On Feb 28, 2019, at 4:54 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > >> The limitation against T.default can be spun, to many users, as a common >> sense >> error check, against uninitialized variables. To more curious users, it can >> be spun >> as a conscious reservation for efficient implementations. > > This is justifiable for (most) ref types, but what about numeric types? I > can imagine many potentially-expensive computations that could reasonably sum > to zero. (And as you point out, the smaller the range, the more silly this > gets, ending with boolean.) So if we're going to have this restriction, it > should be restricted to class types, and the recommended workaround be some > sort of Optional or box. And given that not all values will be null-default, > it rules out any value types for which the zero answer is a reasonable > answer. I think this edge is sharper than it looks.
What I want here can be obtained by forbidding nulls, specifically, for nullable types, and then doing something different for non-nullable types. A translation strategy could deal with non-nullable types (like boolean) by using condy for statics and some other mechanism for non-statics, such as desugaring the type of the field to a reified Optional<int>. Would that have fewer sharp edges? Wrapping an Optional around every nullable non-static reference is conceivable but that seems to be add a disruptive number of indirections, and also Optional itself excludes nulls. We've made the no-null policy decisions for Optional; let's benefit from it for lazies. — John
