On 7/1/15 5:45 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:
>> I know this is just back-of-envelope, but what's wrong with:
>>
>> alias Nullable(T) if(is(T == class)) = T;
>>
>> bool isNull(T)(T t) if(is(T == class)) { return t is null;}
>
> That's what I intended. (Same for pointers and slices, BTW.)
>
> I does however have a slightly different behaviour: In the current
> implementation, there can be instances for which `isNull` returns false,
> but whose payloads are nevertheless `null`.

Oh. Sorry to say this, but that code is just broken. I frankly don't think we should concern ourselves with that use case. I wish I had paid more attention when this was all going down.

-Steve

On 7/1/15 5:45 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:
>> I know this is just back-of-envelope, but what's wrong with:
>>
>> alias Nullable(T) if(is(T == class)) = T;
>>
>> bool isNull(T)(T t) if(is(T == class)) { return t is null;}
>
> That's what I intended. (Same for pointers and slices, BTW.)
>
> I does however have a slightly different behaviour: In the current
> implementation, there can be instances for which `isNull` returns false,
> but whose payloads are nevertheless `null`.

I just realized this. With a Nullable!(T[]), you can have a type where:

x is null
x == null
x.isNull

all have different behavior. I'm really quite unconvinced that this has any good properties. I think we should fix it.

-Steve

On Wednesday, July 01, 2015 08:43:59 Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 7/1/15 5:45 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> > On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:
> >> I know this is just back-of-envelope, but what's wrong with:
> >>
> >> alias Nullable(T) if(is(T == class)) = T;
> >>
> >> bool isNull(T)(T t) if(is(T == class)) { return t is null;}
> >
> > That's what I intended. (Same for pointers and slices, BTW.)
> >
> > I does however have a slightly different behaviour: In the current implementation, there can be instances for which `isNull` returns false, but whose payloads are nevertheless `null`.
>
> I just realized this. With a Nullable!(T[]), you can have a type where:
>
> x is null
> x == null
> x.isNull
>
> all have different behavior. I'm really quite unconvinced that this has any good properties. I think we should fix it.

It most definitely is _not_ good practice, and I would be fine with fixing it, but at the same time, I could see someone screaming about code breakage, though most likely, they'd simply end up triggering bugs in their code that were hidden by the current behavior.

- Jonathan M Davis