(non)nullable types

Jarrett Billingsley jarrett.billingsley at gmail.com
Wed Feb 11 17:45:50 PST 2009


On Wed, Feb 11, 2009 at 8:05 PM, Christopher Wright <dhasenan at gmail.com> wrote:
>
> You'll eventually need to convert between nullable(T) and not_nullable(T).
> This requires runtime checks. A struct NotNull(T) could do the same, with
> some significant disadvantages.

And how is that any different than how it is now?  Currently you do
"if(blah is null) do one thing; else do something else;".  This kind
of pattern can actually be picked up by the compiler and it would say
"hey, blah is null in the first clause but I know it's not null in the
second."  I think Andrei mentioned this as "flow-dependent typing"?
Or something like that.  The "if(auto blah = something) ... else ..."
pattern also fits very nicely with nullable references.

> But making not_nullable the default, I'm not sure how much work that would
> add for me. I know it would add a fair bit for Walter. Having it as an
> option and not the default would probably make it sufficiently annoying that
> people would not use it, in which case it's no better than adding an
> invariant.

If anything, most of your code would probably just go on working as it
has.  The few cases where you actually allow null, you'd have to
annotate the type, and the compiler would be able to do flow-dependent
typing in a vast majority of the cases.  In the other cases, where you
don't expect null (and forgot to check for it), the compiler will
happily point out when you're a moron and pass null to a non-null
parameter.

> On the one hand, not_nullable by default would probably do me no good. On
> the other, it would cost me little effort in most cases, most likely, unless
> I got sufficiently annoyed at all the little cases that I gave up and made
> every variable nullable by default.

Except honestly, the number of cases where you _don't_ want something
to be null far outweighs the number of cases where you _do_.  It's not
exactly as insidious as the "throws" clause.

> It would be cool if we could accompany these discussions with sample
> compilers that implement the feature in question. That way, I could speak
> with some certainty when I said that a proposed feature would be annoying.

It would, wouldn't it!  That would be nice if we had a nice compiler
that we could modify and compile into an EXE.  Like DMD.

FFS.



More information about the Digitalmars-d mailing list