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=?= <schue...@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
