Current sentiment on Nullable.get

[Jonathan M Davis]

On Monday, December 10, 2018 9:02:32 AM MST Steven Schveighoffer via 
Digitalmars-d wrote:
> On 12/10/18 5:01 AM, FeepingCreature wrote:
> > Having recently been reminded that `alias Nullable.get this` exists, I'm
> > considering a pull request to deprecate it. What's the sentiment on
> > `alias Nullable.get this` in the community? My unchanged stance is that
> > it's a blight and an interminable source of impossible to find runtime
> > bugs, and an anti-feature that misses the point of Nullable to provide
> > safe optional types.
> >
> > The typical problem goes like this:
> >
> > 1. A dependency switches from T to Nullable!T.
> > 2. You update your dependencies.
> > 3. Your program still compiles (because Nullable!T silently casts to "T
> > or exception") and you notice nothing.
> > 4. Sometime later, your program crashes in production.
>
> Wow, I didn't realize that get, in production with asserts off, is no
> different than just any T. It's practically useless.
>
> I don't think we can simply deprecate that feature. All you will see is
> people adding "get" to all the accesses, but still resulting in the same
> problem.
>
> I was going to suggest changing the assert to an enforce, but that
> changes the nothrow semantics.
>
> I think we'd be better off adding a new type, which does what people
> want, and deprecating Nullable completely.

Given that it's a bug in the program to access get (be it explicitly or
implicitly) on a Nullable that's null, I don't think that it's at all
appropriate to use an Exception. An assertion makes perfect sense. The only
potential issue I see there is if someone thinks that such a bug is critical
enough that it needs to always be checked for even with -release, in which
case, enforce could be used with an Error. I'm not convinced that it's a
severe enough issue to merit adding a check that's always in place, but it
could be done with Nullable as it stands without breaking code.

- Jonathan M Davis