Nullable or Optional? Or something else?

[Jarrett Billingsley]

On Thu, Sep 3, 2009 at 12:02 PM, Steven
Schveighoffer<schveiguy at yahoo.com> wrote:
> On Wed, 02 Sep 2009 15:39:28 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's
>> Optional).
>>
>> Apparently a good design is to define Optional!T with a minimum of member
>> functions (ideally none) and have it use the "alias this" feature to
>> masquerade as a T. That way Optional!T looks and feels much like a T, except
>> that it supports a function
>>
>> bool isNull(T)(Optional!T value);
>>
>> Am I on the right track? If so, what is the name you'd prefer for this
>> artifact?
>
> I like nullable, but optional will work.
>
> ---
>
> I noticed that in some of your responses, you refer to OptionalRef, Can you
> elaborate on that?  I looked up Nullable for C#, and it specifically says
> that you can't apply the Nullable struct to a non-value type (because
> reference types are nullable).
>
> Since we are in D and not C# and have vastly better template mechanisms, I
> was assuming that Optional!T would simply alias to T if T is a reference
> type already (such as a class or pointer).
>
> This is also going to be better looking if the compiler helps.  Having to do
> isNull(x) all the time instead of x !is null is going to be a pain when you
> aren't sure whether x is an Optional!T or a true reference type (such as a
> class).
>
> It would also solve some other problems.  For instance being able to test if
> Rebindable is null...
>
> I wonder if the compiler could do something nifty like this:
>
> struct S
> {
>  int n;
>  alias n this;
>  static S opNull() { return S(int.min); }
> }
>
> S s;
>
> s = null; // translates to s = S.opNull();
> if(s !is null); // translates to if(s !is S.opNull())
>
> Now you have a "nullable" int type that works for most cases and only
> requires an int storage space.
>
> I don't understand the ramifications on the context-free grammar, but does
> something like this seem feasible?

The semantics here have nothing to do with the grammar. It's not
really that different from operator overloading.