What's Wrong With `alias get this` (tl; dr: it's an implicit conversion that may crash at runtime)

[FeepingCreature]

On Thursday, 30 May 2019 at 18:23:54 UTC, Jonathan M Davis wrote:
> I don't think that there was ever a consensus on it (mostly 
> just one person being really vocal about IIRC). But regardless, 
> IIRC, what prevented it from going any further was that 
> deprecating the alias resulted in deprecation messages when the 
> alias was checked by the compiler even if it wasn't actually 
> used in the code, meaning that you got a lot of extraneous 
> deprecation messages. I believe that the bug was reported, but 
> I don't know what its status is.
>
> - Jonathan M Davis

Addendum: let me just copypaste my reasoning from an ongoing 
github conversation about what's wrong with `alias get this`.

We're using `Nullable` as a stdlib-provided "optional" type, and 
we keep running into issues where we accidentally use 
`Nullable!T` as `T`, or make some field `Nullable` and forget to 
add `isNull` checks, and instead of a nice informative compile 
error we get a runtime crash, potentially arbitrary time later, 
potentially in production.

As I keep semi-joking, "`Nullable` adds pointer semantics to 
arbitrary types, up to and including the null pointer crash". 
It's just bad design. If the compiler can tell that an error may 
occur, it should require it to be handled, _especially_ if the 
alternative is only guarded by an `assert` (which should only be 
for things that really _logically_ cannot happen). Certainly it 
should not silently opt you into an implicit conversion that may 
crash at runtime.