Null References: The Billion Dollar Mistake

Post by [deleted] » Sun, Jan 12, 2020, 1:38 PM UTC

littlecranky67 wrote: post #139

decafbad wrote: post #82

C.A.R Hoare couldn't foresee consequences 55 years ago. That's a small mistake. We should blame language designers who didn't bother to handle the problem after it's been obvious.

Lot of mainstream languages nowadays support non-nullable types, i.e. TypeScript and C# (taken from F#).

Post by kerkeslager » Sun, Jan 12, 2020, 3:13 PM UTC

tsimionescu wrote: post #130

kerkeslager wrote: post #95

Earlier quoted context omitted.

If it really can't ever be null, then it should just be an int, not an Optional . The entire reason that it is an Optional is that it CAN be null. In this hypothetical language, not initializing an int is a compiler error, assigning null to an int is a compiler error, etc. If it's an int it literally cannot be null. What ends up happening in practice is that the null is handled close to where it's created, and the re…

There are normal cases where this can happen. For example, a map should normally return an Optional when you try to retrieve a key's association. However, there may be special cases where you know that a key is present (maybe it is a constant map, maybe you just set the value of that key etc). I do agree that these cases are much rarer than the cases where a value is either always there, or the cases where a value re…

    const myConfig = new Map {
        "height": 72,
        "weight": 160,
    };

    [...]

    var height = myConfig["height"].matchOptional(
        ifNull: () => 0,
        ifValue: i => i,
    );

    const myConfig = struct {
        height: 72,
        weight: 160
    };

    var weight = myConfig.weight;

    dictionary[word] = getDefinition();
    let definition = dictionary[word].matchOptional(
        ifNull: () => "",
        ifValue: d => d,
    );

    let definition = getDefinition();
    dictionary[word] = definition;

    const defaultHeight = 72;
    const defaultWeight = 160;

    JsonObject configJson = json.loadFile("config.json");

    const config = struct {
        height: configJson["height"].matchOptional(
            ifNull: defaultHeight,
            ifValue: v => v.asInt(notInt: v => throw Exception("Invalid height \"{}\" in config.".format(v)))
        ),
        weight: configJson["weight"].matchOptional(
            ifNull: defaultWeight,
            ifValue: v => v.asInt(notInt: v => throw Exception("Invalid weight \"{}\" in config.".format(v)))
     };

Post by LorenPechtel » Sun, Jan 12, 2020, 4:59 PM UTC

to11mtm wrote: post #145

iCarrot wrote: post #114

Earlier quoted context omitted.

They are called Nullable types in C# and must be declared with `?` after the type. But, Nullable .HasValue check is not forced and Nullable .Value will throw a different exception instead if it is null (InvalidOperationException).

Well, Depends on which type you are referring to (Which is part of what pains me with nullable ref types, as nice as it is to have) If it's a value type (T), ? will make it Nullable and provide the behavior described. Reference types however can always be null, and do not have a .HasValue as exampled above. However newer versions of C# let you declare nullable references on a compiler level, but rather than HasValue/…

Post by scientific1 » Mon, Jan 13, 2020, 1:30 AM UTC

tene wrote: post #131

davidgay wrote: post #100

Earlier quoted context omitted.

I don't consider 'option' types to have interesting semantic differences with nullable types. YMMV. But beyond that, the absence of nullable references (really, a valid default value for every type) is a problem for record/object/struct initialisation - you either have to provide all values at allocation time, or attempt to statically check that the object is fully initialised before any use - Java has rules to that…

The difference is that you can't accidentally use an option as a pointer without checking it first, and when your APIs specify a non-nullable pointer you can rely on the callers to have checked for null. When you're reading or writing a function that accepts a non-nullable reference, you never have to worry about whether the argument is null or not. It's easier to get right, constrains the scope of certain types of e…

Post by int_19h » Mon, Jan 13, 2020, 7:35 AM UTC

tsimionescu wrote: post #132

int_19h wrote: post #94

Earlier quoted context omitted.

This is a corner case, though, and one that is itself a code smell (i.e. in well-written code, it should be very rare). Having implicit null references, and implicit null checks on dereference, optimized for rare a corner case to the detriment of safety in typical code patterns, is a bad thing. And it definitely is a significant source of errors in managed memory languages, from my experience in C# and Python. It can…

> Having implicit null references, and implicit null checks on dereference, optimized for rare a corner case to the detriment of safety in typical code patterns, is a bad thing. Yes, I completely agree. I was just trying to point out that Optional is not a 100% air-tight solution, I think the problem of handling missing values is just too general to actually have a 100% solution. Still, the perfect shouldn't be the e…