Is there a strong reason for Nullable's alias get this?

[FeepingCreature]

On Wednesday, 18 April 2018 at 10:01:17 UTC, Nick Treleaven wrote:
> On Wednesday, 18 April 2018 at 08:24:14 UTC, FeepingCreature 
> wrote:
>> If nobody objects, I'll make a PR to deprecate it.
>
> +1. Nullable has received some improvements lately, it would be 
> great if `get` was no longer implicit. For new code, it is 
> trivial to write `.get` to convert to the original type. For 
> old code, deprecation is a good solution. (Permanent 
> deprecation can solve the problem of breaking code in the 
> longer term).

I agree; the important thing to me is that code that uses the 
implicit conversion is at least highlighted in some way.

> There is an argument for making `get` *require* a fallback 
> value rather than a default `.init` argument, to make the 
> conversion completely explicit, but this is perhaps a change 
> too far considering how lax we currently are. A third way would 
> be to require a fallback argument only when the original type 
> doesn't have a good invalid value like null. At least null 
> dereference, if triggered, will be detected immediately upon 
> execution. An unexpected zero-value might go undetected for a 
> long time.

An argument against making get require a fallback is that D lacks 
a good abstraction for customizing control flow, so we don't have 
a good way to say "if Nullable contains a value, do this with the 
value, else do this fallback," meaning we have to do if (isNull) 
{ get; } or such. That said, I'm pretty sure that get will throw 
anyways if invoked without a default value.