Revisiting default values

[Kevin Bourrillion]

Yes, that would satisfy me if Bucket #3 acknowledges that it's both for
cases where a default is impossible as well as cases where it is simply
judged to be too harmful.


On Fri, Jul 10, 2020 at 1:02 PM Dan Smith <daniel.smith at oracle.com> wrote:

> > On Jul 10, 2020, at 12:46 PM, Kevin Bourrillion <kevinb at google.com>
> wrote:
> >
> > My reason for complaining here is not just about the java.time types
> themselves, but to argue that this is an important 4th bucket we should be
> concerned about. In some ways it is a bigger problem that Bucket #3 "no
> good default", since it is an actively harmful default.
> >
> > For all of these types, there is one really fantastic default value that
> does everything you would want it to do: null. That is why these types
> should not become inline types, or certainly not val-default inline types,
> and why Error Prone will have to ban usage of `.val` if they do.
>
> Appreciate the thoughts, this is definitely relevant.
>
> For the purpose of this discussion, I'd say you're arguing for these
> classes to move to Bucket #3. Because then the question becomes, just like
> for the other classes there: do we use the Bucket #3 strategies to support
> these as inline classes, or do we give up and leave them as identity
> classes?



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com