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.

Thoughts?

On 2018-12-10 11:01, 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.

I agree that `alias Nullable.get this` should be deprecated. I think the whole Nullable should be deprecated and replaced with Optional.

-- 
/Jacob Carlborg

On Monday, 10 December 2018 at 10:01:45 UTC, 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.
>
> Thoughts?

Sounds like a step forward, deprecating that.

Do people consider Nullable a type of Optional thing in general? I have a written a bit more details here [0] but basically I don't think deprecating .get is enough to make it "safe" - granted - depending on what safe means. In the context of D a segfault is safe so maybe that's ok. But then deprecating get doesn't add safety in that context anyway. And, I've never really considered Nullable as something that provides Optional semantics. But maybe that was it's intention?

[0] https://github.com/aliak00/optional/blob/03e0dc0594f1f19274389227e67dd3fba00a9d3f/README.md#what-about-stdtypeconsnullable-and-stdrangeonly

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.

-Steve

On Monday, 10 December 2018 at 15:47:53 UTC, aliak wrote:
> [snip]
>
> Sounds like a step forward, deprecating that.
>
> Do people consider Nullable a type of Optional thing in general? I have a written a bit more details here [0] but basically I don't think deprecating .get is enough to make it "safe" - granted - depending on what safe means. In the context of D a segfault is safe so maybe that's ok. But then deprecating get doesn't add safety in that context anyway. And, I've never really considered Nullable as something that provides Optional semantics. But maybe that was it's intention?
>
> [0] https://github.com/aliak00/optional/blob/03e0dc0594f1f19274389227e67dd3fba00a9d3f/README.md#what-about-stdtypeconsnullable-and-stdrangeonly

Does it make sense to deprecate Nullable as a whole, rather than just that piece? Why would I use Nullable when I can use your optional library?

On Mon, Dec 10, 2018 at 05:07:10PM +0000, jmh530 via Digitalmars-d wrote:
> On Monday, 10 December 2018 at 15:47:53 UTC, aliak wrote:
> > [snip]
> > 
> > Sounds like a step forward, deprecating that.
> > 
> > Do people consider Nullable a type of Optional thing in general? I have a written a bit more details here [0] but basically I don't think deprecating .get is enough to make it "safe" - granted - depending on what safe means. In the context of D a segfault is safe so maybe that's ok. But then deprecating get doesn't add safety in that context anyway.  And, I've never really considered Nullable as something that provides Optional semantics. But maybe that was it's intention?
> > 
> > [0] https://github.com/aliak00/optional/blob/03e0dc0594f1f19274389227e67dd3fba00a9d3f/README.md#what-about-stdtypeconsnullable-and-stdrangeonly
> 
> Does it make sense to deprecate Nullable as a whole, rather than just that piece? Why would I use Nullable when I can use your optional library?

AFAIK, Nullable was intended for giving an extra "null" value to by-value POD types.  Outside of that narrow use case, it's really not a very nice API at all, and the implementation is a bit simplistic, dating from an earlier time when we didn't have as many attributes / new features as we do today. As a result, there are some very nasty corner cases where it behaves in counterintuitive ways that can't be fixed without breaking existing code in evil ways. Its name is also a bit misleading, esp. when you apply it to by-reference types.

There have been various attempts to give it a facelift, but so far none has made it through.  I'm inclined to agree with deprecating it, except I dread the long painful process of getting a replacement added to Phobos.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

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

On Monday, 10 December 2018 at 10:01:45 UTC, 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.
>
> Thoughts?

I would deprecate "alias get this", rename the version of "get" that takes a fallback to "orDefault" and add "alias orDefault this".

Going further, I'd also deprecate the weird "nullify" and "isNull", and instead add overloads of opAssign and opEquals for null.

On Mon, 10 Dec 2018 10:01:45 +0000, 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?

I already thought that Nullable was clunky (!nullable.isNull: is it false that the thing has no value? -- I just want to know if it has a value). With that alias, I'm kind of horrified.

Why does this even exist? Why is it Nullable instead of Optional or Maybe? The thing about null is that it segfaults when you use it, which is not the key thing about an optional value. Why does it have this automatic bug pit?

On Monday, December 10, 2018 3:01:45 AM MST FeepingCreature via Digitalmars- d 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.
>
> Thoughts?

Personally, I don't think that it's all that big a deal, but I'm not really against deprecating the alias either. Given that we don't have implicit construction in D, the alias already fails at its goal of making a Nullable!T work like a T (though even _with_ implicit construction, swapping out a T for a Nullable!T would break code involving template constraints, so implicit construction isn't the only problem there, but it's the most obvious one). So, in general, I'm inclined to argue that it's just better practice to use get explicitly, and I wouldn't mind it being deprecated.

However, IIRC, someone already tried to deprecate the alias and ran into a compiler bug that prevented it - though unfortunately, I can't find the bug report at the moment. I recall it being an issue with getting deprecation messages from the alias even when it wasn't used explicitly, but when I try a simple test case, I get a different bug entirely. This code snippet

struct S
{
    int get()
    {
        return 42;
    }

    deprecated alias get this;
}

void main()
{
    S s;
    int i = s;
}

doesn't result in any deprecation messages at all. Based on that, without some compiler fixes, it's not actually possible to deprecate the alias.

- Jonathan M Davis