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

2018-04-21 Thread Nick Treleaven via Digitalmars-d
On Wednesday, 18 April 2018 at 13:36:15 UTC, FeepingCreature wrote: That said, I'm pretty sure that get will throw anyways if invoked without a default value. Not in release mode, but I suppose that doesn't matter. I've made a pull to update the docs to reflect this:

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

2018-04-18 Thread FeepingCreature via Digitalmars-d
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

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

2018-04-18 Thread Nick Treleaven via Digitalmars-d
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

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

2018-04-18 Thread FeepingCreature via Digitalmars-d
If nobody objects, I'll make a PR to deprecate it.

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

2018-04-16 Thread SimonN via Digitalmars-d
On Monday, 16 April 2018 at 10:10:56 UTC, FeepingCreature wrote: Nullable!T to T is a narrowing conversion, since T cannot express the null case. Therefor, it must not be implicit. I agree with this. To even reach for a Nullable type in one's codebase incurs a cost -- the need is substantial

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

2018-04-16 Thread FeepingCreature via Digitalmars-d
Addendum: The general principle is that a "narrowing conversion" should never be implicit. An example of a narrowing conversion is float to int, or int to short. In the case of integer types, D already follows this rule. Nullable!T to T is a narrowing conversion, since T cannot express the

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

2018-04-16 Thread FeepingCreature via Digitalmars-d
Say that we have a function that returns an int. We assign it to an auto variable and pass that to another function which takes an int. All is well. Say we change the function to return a Nullable!int. We expect the compiler to warn us that we must now check for isNull; however, what we

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

2018-04-16 Thread Jonathan M Davis via Digitalmars-d
On Monday, April 16, 2018 08:34:13 FeepingCreature via Digitalmars-d wrote: > I think `alias get this` is a misfeature. > > If at all possible, compiletime errors should be preferred over > runtime errors. The point of Nullable is that the value contained > within may be absent. Considering the

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

2018-04-16 Thread FeepingCreature via Digitalmars-d
I think `alias get this` is a misfeature. If at all possible, compiletime errors should be preferred over runtime errors. The point of Nullable is that the value contained within may be absent. Considering the prevalence of type inference and UFCS chaining in idiomatic D, it is very possible