• my name (unregistered)

    Tern Around Bright eyes

  • Prime Mover (unregistered)

    And I was expecting someone to have mis-spelt "ternary" somewhere in the post.

    No, just lack of attention to detail.

  • Sole Purpose Of Visit (unregistered)

    Just out of interest, Remy, when you say you prefer optional types, do you mean actual optional types (eg Haskell's Maybe) or simply a nullable native type?

    I'm asking because I'm trying to steer cow-orkers (oops, a pun) towards Maybe in C#. It's hard work to wean people off nulls.

  • Brian (unregistered) in reply to Sole Purpose Of Visit

    Not Remy, but this is something I've also been dealing with lately. Personally, I've found nullable reference types in C# to be quite useful (by which I mean annoying enough to push people to resolve the nulls as early as possible and then use non-nullable refs from then on), assuming you're using a version of the language that supports that feature.

  • (author) in reply to Sole Purpose Of Visit

    Maybe I'm not totally up on type theory, but aren't nullables just a special case of optional types? Is there some special magic that Haskell's Maybe or C++'s Optional do that the nullable doesn't? I don't think there is. In C#, nullables are implemented basically the same way- Nullable<T> as a wrapper class around some object which might be null. C# just chucks a bunch of syntatic sugar in there to make it read better.

  • Brian (unregistered)

    This article's (headline) is for the burds.

  • Kythyria (unregistered) in reply to Remy Porter

    Nullable is pretty much Option/Maybe, yes. The catch is that C# references are always able to be null unless you turn on the nullability annotations, a fact that makes all of this less useful, and probably why Nullable was originally introduced to work only on value types.

    C# also didn't let you say if(Foo.HasValue(out var v)) at the time, which helps the ergonomics a lot.

  • Sole Purpose Of Visit (unregistered) in reply to Remy Porter

    Maybe (or Optional in some language libraries) can be considered as a wrapper for a value, rather than a directly nullable type. (It's actually an applicative functor, but who cares? The only thing you need to know is that you need to bind to something to get the value out.)

    You can work directly with a nullable type in C#:

                        double? fred = null;
                    if (fred == 1)
                    {
                        System.Console.WriteLine(fred);
                    }

    ... but that isn't really much of an improvement on a naked null. In this case you will get a null exception. If you use a Maybe and it binds to an if/else (ie it doesn't allow you to deal with the wrapped value directly) then you force the consumer to consider the possibility that the wrapped value is null.

    At least, that's the way it works in my implementation. Ideally you would use it in SelectMany for ILists (there is an implementation in GitHub), but that's only really useful if everything you deal with is an IList.

  • Sole Purpose Of Visit (unregistered) in reply to Remy Porter

    Then again, Nullable<T> appears to be pretty much the same thing. Except that it's only available in 8.0, and it needs to be switched on, and I haven't used it, but as far as I can see you get a compiler warning rather than being forced to bind to the underlying value.

  • gordinfish (unregistered)

    Laughs in named parameters.

    I'm rather surprised that no one has brought that up, as they are far superior in a lot of ways to ye olde positional arguments.

  • Kythyria (unregistered) in reply to Remy Porter

    I should probably also point out that Rust and Haskell make Option/Maybe out of sum types (ie, "a Foo can be a Bar, Baz, or Quux", where any of those things can be just the name or include some data). So a bunch of ergonomics and implementation details comes from how the language handles those.

    In particular, an Option-al reference (in a lang where references are never null) may well be implemented as a nullable reference (normally sum types are done as tagged unions). And pattern matching and destructuring assignment can be used to get at the inner value.

  • (author) in reply to Sole Purpose Of Visit

    Code like that doesn't trigger an exception.

      static void Main() {
      double? fred = null;
    if (fred == 1)
    {
        System.Console.WriteLine(fred);
    }
    Console.WriteLine("This is fine.");
  }
}

    Prints "This is fine". Because the nullable operator is just a bit of syntatic sugar around Nullable<double>, so fred does have a value and is not a null reference- the contents of fred are null. Similarly, if you did fred?.ToString() that's actually going through the Nullable wrapper and just hiding the details from the developer.

    And I'm not sure what you mean about Version 8- Nullable<T> has been in .NET since .NET 2.0: https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1?view=net-7.0#applies-to

    (There's a debate to be had about if that syntatic sugar actually makes the language better- more ergonomic, yes, but if you look at the Linq query syntax, you can see lots of opportunity for confusion because the code you write is nothing like what the compiler sees)

  • NoLand (unregistered)

    Be sure to keep your nulls fresh. Stale nulls are the primary cause of null pointer exceptions! ;-)

  • (nodebb) in reply to Sole Purpose Of Visit

    I think you mess up your example, because this translates to: `` .locals init ( [0] valuetype [System.Runtime]System.Nullable1<float64> fred, [1] bool, [2] valuetype [System.Runtime]System.Nullable1<float64>, [3] float64 )

    IL_0000: nop
IL_0001: ldloca.s 0
IL_0003: initobj valuetype [System.Runtime]System.Nullable`1<float64>
IL_0009: ldloc.0
IL_000a: stloc.2
IL_000b: ldc.i4.1
IL_000c: conv.r8
IL_000d: stloc.3
IL_000e: ldloca.s 2
IL_0010: call instance !0 valuetype [System.Runtime]System.Nullable`1<float64>::GetValueOrDefault()
IL_0015: ldloc.3
IL_0016: ceq
IL_0018: ldloca.s 2
IL_001a: call instance bool valuetype [System.Runtime]System.Nullable`1<float64>::get_HasValue()
IL_001f: and
IL_0020: stloc.1
IL_0021: ldloc.1
IL_0022: brfalse.s IL_0032

IL_0024: nop
IL_0025: ldloc.0
IL_0026: box valuetype [System.Runtime]System.Nullable`1<float64>
IL_002b: call void [System.Console]System.Console::WriteLine(object)
IL_0030: nop
IL_0031: nop

IL_0032: ret``

    So perfectly fine and works as intended with no NullReferenceException potential.

  • (nodebb) in reply to Remy Porter

    Hehe, you shouldn't say your "bit of syntatic sugar" when someone of the .net language team is around. After all they had to complete respec the CTS to allow a value type be assigned null, changed the compiler accordingly and did a lot of magic to make everything work a smoothly as it is.

    After all, nullable value types in C# are not reference types, they are value types boxing the value type with an additional boolean member.

  • (nodebb) in reply to Sole Purpose Of Visit

    I use Optional<T> types in Java (not familiar with C#, but I assume Nullable<T> is the same,) but mostly to make the code more fluent and as documentation. Since values can be null anywhere short of using piles and piles of @NotNull annotations everywhere, it really doesn't make a semantic difference.

    A lot of people are talking about Haskell's Maybe type. In the ML family of languages like Haskell and OCaml, it really does make a difference. They don't have nulls; everything is a value. The only way to make something nullable is to be explicit about it and make it a "Maybe a" in Haskell or an " 'a option" in OCaml. The fact that it's done as a sum type (tagged union, variant, whatever you want to call it) is more of an implementation detail. It could just as well be built-in to the language semantics. Both Swift and Typescript do this by allowing types to be declared as "<type-name>?" to indicate optional types.

    IIRC, Kotlin is a JVM language takes the same approach as the ML family of languages in that everything in non-null by default and nulls must be explicitly annotated.

  • Sole Purpose Of Visit (unregistered) in reply to Remy Porter

    Can't yet see WoO's comment, which will probably prove me wrong.

    I've not done a good job of explaining my problem with returning nulls, which is programmers, basically. Let's try this with a non-native type:

    static void Main() {
      Widget fred = GetSomethingThatMightBeNull();
      fred.Print();
}

    This will of course throw an exception if fred is null. And it may be that the original implementation of GetSomethingThatMightBeNull never returns a null, in which case nobody cares. Nobody will really care when GetSomethingThatMIghtBeNull is reimplemented such that null is returned on the 4th July of every year that is divisible by four but is not a leap-year.

    Then, suddenly, a perfectly innocent update causes GetSomethingThatMightBeNull to return a null every now and again during a normal session.

    It's all about semantics, really. If you're going to force the consuming call to deal with nulls, then damn well force that semantic. Maybe forces that semantic. Nullable objects do not. (ANd trust me, I'm dealing with dozens of the bloody things in my current code base.)

  • (nodebb)

    Technically, this code is "terning" nulls into nulls, not values.

  • (nodebb)

    NULL, the worst thing ever created. Except all of the alternatives were worse.

  • Kythyria (unregistered) in reply to TheCPUWizard

    Whether nullptr is better or worse than the alternatives seems to depend on whether said alternatives are retrofitted and how they work. Sum types work really well, with the right support, but if you staple any replacement for null on after the fact rather than have them from the start, there'll be lots of places that shouldn't be nullable but aren't declared null-free.

    The refactoring to add that declaration is frequently easy, there's just a lot of it, and inevitably external libs will be unfixable.

  • Craig (unregistered) in reply to Remy Porter

    Be very careful about doing comparisons involving potentially nullable values. The truth tables aren't always what you would expect. I ran into trouble with this where I got the opposite behavior of what I would expect when doing an If on a Boolean?.

    VBA-heritage VB had specifically designed truth tables for null. I don't remember, offhand, whether the truth tables for Boolean? follow the historical truth tables.

    In the specific case here, I would expect the result of "fred == 1" to be boolean? so the behavior of the "if" depends on how it handles a boolean? without a value.

Leave a comment on “Terning Nulls into Values”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article