I’m having a hard time imagining where this is useful. If I’m trying to assign to a property, but encounter an intermediate null value in the access chain, just skipping the assignment is almost never going to be what I want to do. I’m going to want to initialize that null value.

• moogly

  today at 1:00 AM

  I'm also not sure I have a lot of code where this would be useful, but adding it to the language I don't feel makes it worse in any way; in fact, it makes it more consistent since you can do conditional null reads and conditional null method invocations (w/ `?.Invoke()`), so why not writes too.

  • layer8

    today at 1:09 AM

    “Why not?” is never a good-enough reason to add a new language feature.

    If it’s rarely used, people may misinterpret whether the RHS is evaluated or not when the LHS doesn’t exist (I don’t actually know which it is).

    Optional operations and missing properties often require subtle consideration of how to handle them. You don’t want to make it too easy to say “whatever”.

    • moogly

      today at 1:18 AM

      > people may misinterpret whether the RHS is evaluated or not when the LHS doesn’t exist

      I fully expect no RHS evaluation in that case. I think the fear is misplaced; it's one of those "why can't I do that when I can do this" IMO. If you're concerned, enable the analyzer to forbid it.

      There are already some really overly paranoid analyzers in the full normal set that makes me wonder how masochistic one can be...

• today at 12:55 AM

• Quarrelsome

  today at 1:09 AM

  improving crappy codebases without breaking anything. Bad .NET developers are forever doing null checks because they write weird and unreliable code. So if you have to fix up some pile of rotting code, it can help you slowly iterate towards something more sane over time.

  For example in my last gig, the original devs didn't understand typing, so they were forever writing typing code at low levels to check types (with marker interfaces) to basically implement classes outside of the classes. Then of course there was lots of setting of mutable state outside of constructors, so basically null was always in play at any moment at any time.

  I would have loved this feature while working for them, but alas; they were still on 4.8.1 and refused to allow me to upgrade the codebase to .net core, so it wouldn't have helped anyway.

  • zdragnar

    today at 3:05 AM

    Unfortunately, I suspect this will just makes it easier to keep writing sloppy code.

• mkoubaa

  today at 1:23 AM

  Monad-maxxing has ruined many a language

  • chowells

    today at 3:16 AM

    This is a functor, not a monad. Also, it's implemented really poorly. If only more languages actually implemented monads well. You wouldn't need special case junk like this.

I'm a Java fan so I'm contractually required to dis c#, but actually I kinda like this. It reduces boilerplate. Yes, it could be abused but this is what code review is for.

More concise? Yes.

More readable? I'm less convinced on that one.

Some of those edge cases and their effects can get pretty nuanced. I fear this will get overused exactly as the article warns, and I'm going to see bloody questions marks all over codebases. I hope in time the mental overhead to interpret exactly what they're doing will become muscle memory...

• DimmieMan

  today at 1:20 AM

  And more better? I'm not sure either.

  In all these examples I feel something must be very wrong with the data model if you're conditionally assigning 3 levels down.

  At least the previous syntax the annoyingness to write it might prompt you to fix it, and it's clear when you're reading it that something ain't right. Now there's a cute syntax to cover it up and pretend everything is okay.

  If you start seeing question marks all over the codebase most of us are going to stop transpiling them in our head and start subconsciously filtering them out and miss a lot of stupid mistakes too.

• monocularvision

  today at 12:42 AM

  Swift has had this from the beginning, and it doesn’t seem to have been a problem.

• arwhatever

  today at 12:01 AM

  What?.could?.possibly?.go?.wrong?.

  • esafak

    today at 12:11 AM

        if (This) {
            if (is) {
                if (much) {
                    if (better) {
                        println("I get paid by the brace")
                    }
                }
            }
        }

    • kazinator

      today at 12:22 AM

      False dichotomy. The problem is that the syntax implements a solution that is likely wrong in many situations and pairs with a bad program design. Maybe when we have this:

        what?.could?.possibly.go?.wrong = important_value()
      

      Maybe we want code like this:

        if (!what)
          what = new typeof(what); // default-construct representative instance
      
        if (!what.could)
          what.could = new typeof(what.could);
      
      
        if (!what.could.possibly.go)
          what.could.possibly.go = new typeof(what.could.posssibly.go)
      
      
        // now assignment can take place and actually retain the stored value
        // since we may have allocated what, we have to be sure
        // we propagate it out of here.
      
        what.could.possibly.go.wrong = important_value();
      
      

      and not code which throws away the value (and possibly its calculation).

      Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.

      What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?

      • Dylan16807

        today at 2:40 AM

        > Maybe we want code like this

        It should be clear enough that this operator isn't going to run 'new' on your behalf. For layers you want to leave missing, use "?.". For layers you want to construct, use "??=".

        > Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.

        If you start with the assignment, then it's important and you want it to go somewhere.

        If you start with the variable, then if that variable doesn't have a home you don't need to assign it anything.

        So whether you want to skip it depends on the situation.

        > What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?

        Do you have the same objection with the existing null-conditional operators? Looking at the operators is important and I don't think this makes the "I didn't notice that operator" problem worse in a significant way.

      • Quarrelsome

        today at 1:30 AM

        NullReferenceException, in line 7.

        you didn't null check possibly.go.

      • esafak

        today at 1:06 AM

        Just because you can't do assignments like that, it doesn't mean you shouldn't use null coalescing for reads. What exactly could go wrong?

    • jayd16

      today at 2:31 AM

          if (Actually 
              && Actually.you
              && Actually.you.would
              && Actually.you.would.write
              && Actually.you.would.write.it
              && Actually.you.would.write.it.like) {
                  return this;
          }

    • muti

      today at 12:16 AM

        if (!same) {
          return;
        }
      
        if (!number) {
          return;
        }
      
        if (!of_braces) {
          return;
        }
      
        println("but easier to read")

      • esafak

        today at 12:21 AM

        Yes, you should definitely unnest functions and exit early. But the null-coalesced version is shorter still.

  • kazinator

    today at 12:16 AM

    Nothing to worry about:

      What?.could?.possibly?.go?.wrong?
    

    Not so convinced:

      What?.could?.possibly?.go?.wrong = important_value()
    

    Maybe the design is wrong if the code is asked to store values into an incomplete skeleton, and it's just okay to discard them in that case.

    • huflungdung

      today at 2:45 AM

      [dead]

• h4x0rr

  today at 12:15 AM

  Oh come on just learn it properly it's not a big deal to read it

It's starting to feel like C# is going down the path of C++. Tons of features that introduce subtleties and everybody has their own set of pet features they know how to use.

But the code gets really hard to understand when you encounter code that uses a subset you aren't familiar with. I remember staring at C++ codebases for days trying to figure out what is going on there. There was nothing wrong with the code. I just wasn't too familiar with the particular features they were using.

• koyote

  today at 2:11 AM

  There's a couple reasons I disagree with you on this (at the moment; as given enough time I am sure C# will also jump the shark):

  * The above is just applying an existing (useful) feature to a different context. So there isn't really much learning needed, it now just 'works as expected' for assignments and I'd expect most C# engineers to start using this from the get go.

  * As a C# and C++ developer, I am always excited to hear about new things coming in C++ that purportedly fix some old pain points. But in the last decade I'd say the vast majority of those have been implemented in awful ways that actually make the problem worse (e.g. modules, filesystem, ...). C#'s new features always seem pretty sound to me on the other hand.

• jayd16

  today at 2:23 AM

  The difference is the language syntax choices are good. There's no "what does this const refer to" type confusion.

Love to see conciseness for the sake of readability. Honestly I thought this was already a thing until I tried it a year ago…

I’m glad it’s now a thing. It’s an easy win, helps readability and helps to reduce the verbosity of some functions. Love it. Now, make the runtime faster…

I wonder if this supports a cleaner way to throw when the target property's parent object is null? With null-coalescing assignment, you can do the following which will throw when 'x' is null:

  string x = null;
  string y = x ?? throw new ArgumentException("x is null");

  customer?.Name = newName ?? throw new InvalidOperationException("customer is null");

  (customer ?? throw new InvalidOperationException("customer is null")).Name = newName ?? throw new ArgumentException("newName is null");

I’d rather be explicit. If the value is null then it should be explicitly handled.

I feel like this is another step in the race to add every conceivable feature to a language, for the sake of it.

• xboxnolifes

  yesterday at 11:50 PM

  This is explicit though. The question mark operator is the developer explicitly asking for this behavior.

• today at 2:32 AM

• yesterday at 11:18 PM

At least so far, my instinct is that we should turn this off/ ensure it is never turned on, as it seems likely to be a foot gun.

I couldn't imagine what a "Null-Conditional Assignment" would do, and now I see but I don't want this.

Less seriously, I think there's plenty of April Fools opportunity in this space. "Null-Conditional Function Parameters" for example. Suppose we call foo(bar?, baz?) we can now decide that because bar was null, this is actually executing foo(baz) even though that's a completely unrelated overload. Hilarity ensues!

Or what about "Null-Conditional Syntax". If I write ???? inside a namespace block, C# just assumes that when we need stuff which doesn't exist from this namespace it's probably just null anyway, don't stress. Instead of actual work I can just open up a file, paste in ???? and by the time anybody realises none of my new "classes" actually exist or work I've collected my salary anyway.

Nice feature! (we had in Ruby for many years)

Like Ruby safe navigation operator `&` and kotlin, groovy and swift's `?`

never using nulls is liberating. this is syntactic sugar for dealing with nulls. definitely welcome though, and definitely will be abused (which cant be done when nulls are actually banished)

Looks interesting & I'm excited to try this out myself. I like the more verbose null/error handling personally in professional code, but maybe that's because im still working in framework! I'll certainly be using these in my personal projects that'll be on .NET 10

• actionfromafar

  yesterday at 11:29 PM

  You can use newer LangVersion in framework too.

I'm working on a Unity game and I'm so annoyed I can't use all of the new fancy c# features

> if (customer?.Profile is not null) >{ > // Null-coalescing (??) > customer.Profile.Avatar = request.Avatar ?? "./default-avatar.jpg"; >}

Isn't this over engineered? Why not allow the assignment but do nothing if any of the intermediate objects is null (that's how Kotlin does it).

• LelouBil

  today at 12:11 AM

  That's what's new in c#14, it allows you to do

      customer?.Profile?.Avatar = "thing" 
  

  And will do nothing if the left hand side is null (not throw a null reference exception anymore)

So like ruby's '&.' null safe chaining

• Dylan16807

  today at 2:47 AM

  Yes but they already had it for non-assigning uses.

I'm looking forward to being able to use this. It doesn't sound like much but those extra three lines and variable assignment is duplicated a ton of times across our codebase so it'll be a nice change

Isn't this more confusing? Because it skip the code if the value is null and I don't think it is normal to follow the flow assuming nothing has happened.

• gus_massa

  yesterday at 11:20 PM

  From the article:

  > If config?.Settings is null, the assignment is skipped.

  If the right hand expression has side effects, are they run? I guess they do, and that would make the code more predictable.

  • today at 2:24 AM

  • Izikiel43

    today at 1:00 AM

    From the article as well:

    Side-Effect Prevention When a null-conditional statement assignment is evaluated, the right-hand side of the expression is not executed unless the left-hand side is defined.

    • gus_massa

      today at 2:16 AM

      Thanks. I missed it.

      I really dislike that, because it hides the control flow too much. Perhaps I'm biased by Racket, where it's easy to define something weird using macros, but you should not do unexpected weird things.

      For example you can define vector-set/drop that writes a value to a position of a vector, but ignores the operation when the position is outside the vector. For example

        (vector-set/drop v -2 (print "banana"))
      

      With a macro is possible to skip (print "banana") because -2 is clearly out of range, but if you do that everyone will hate you.

• electroly

  yesterday at 11:06 PM

  That's already the case for the null coalescing operator when it ends in a method call: the method call is skipped if the base is null. For instance, we can invoke event handlers with "myEvent?.Invoke(...);" and the call will be skipped if there are no event handlers registered, and this is the canonical way to do it.

• cjbgkagh

  yesterday at 10:50 PM

  It’s for the use case where they’d skip it anyway so that would be intended behavior.

• accrual

  yesterday at 10:59 PM

  > I don't think it is normal to follow the flow assuming nothing has happened.

  I think it is for situations where the programmer wants to check a child property but the parent object may be null. If the parent is expected to be null sometimes, the syntax lets the programmer express "try to get this value, but if we can't then move on" without the boilerplate of explicitly checking null (which may be a better pattern in some cases).

  It's sort of like saying:

  - Get the value if you can, else move on. We know it might not be there and it's not a big deal.

  v.s.

  - The value may not be there, explicitly check and handle it because it should not be null.

  • BoiledCabbage

    today at 12:27 AM

    Your summary is almost correct but replace where you used "get" with "set".

Null conditional assignment is bunk.

When you have an expression P which names a mutable place, and you execute P := X, the contract says that P now exhibits the value X, until it is assigned another value.

Conditional assignment fucks this up. When P doesn't exist, X is not stored. (Worse, it may even be that the expression X is not evaluated, depending on how deep the fuckery goes.)

Then when you access the same expression P, the conditional assignment becomes conditional access and you get back some default value like a nil.

Store X, get back nil.

That's like a hardware register, not a durable memory model.

It's okay for a config.connection?.retryPolicy to come up nil when there is no config.connection. It can be that the design makes nil a valid retry policy, representing some default. Or it could be that it is not the case, but the code which uses connection? handles the nil soon afterward.

But a store to config.connection?.retryPolicy not having an effect; that is dodgy.

What you need for config.connection? to do when the expression is being used to calculate a mutable place to assign to is to check that config.connection is null, and in that case, instantiate a representative instance of something which is then assigned to config.connnection, such that the config.connection.retryPolicy place then exists and the assignment can proceed.

This recognizable as a variation on COW (copy-on-write); having some default instance for reading, but allocating something on writing.

In a virtual memory system, freshly allocated memory can appear to contain zero bytes on access due to all of its pages being mapped to a single all-zero frame that exists in the entire system. Conceptually, the hardware could do away with even that all-zero frame and just have a page table entry which says "this is a zero-filled page", so the processor then fakes out the zero values without accessing anything. When the nonexistent page is written, then it gets the backing storage.

In order to instantiate settings.connection? we need to know what that has to be. If we have a static type system, it can come from that: the connection member is of some declared type of which a representative instance can be produced with all constructor parameters defaulted. Under a dynamic paradigm, the settings object can have a handler for this: a request to materialize a field of the object that is required for an assignment.

If you don't want a representative config.connection to be created when config.connection?.retryPolicy is assigned, preferring instead that config.connection stays null, and the assignment is sent to the bit buckets, you have incredibly bad taste and a poor understanding of software engineering and programming language design --- and the design of your program is scatter-brained accordingly.

• Dylan16807

  today at 3:14 AM

  A representative config.connection being made out of nothing sounds pretty bad to me. If you want to make sure the value doesn't disappear, you shouldn't be using conditional assignment in the first place.

  The config example isn't the best, but instead imagine if it was just connection.?retryPolicy. After you set connection?.retryPolicy it would be weird for reading it back to be null. But it would be just as weird for connection?.retryPolicy to not be null when we never established a connection in the first place.

  The copy on write analogy is tempting but what you're describing only works when the default value is entirely made of nulls. If you need anything that isn't null, you need to actually make an object (either upfront or on first access). And if you do that, you don't need ?. anymore.

• NetMageSCW

  today at 1:06 AM

  Apparently you do t use if in your code?

Is .NET entering its twilight years as a tech people build new things with?

I just can't imagine Gen Z wanting to start a project in C#.

I realise there are still .NET shops, and I still talk to people who do it daily, but ours is a field driven by fashion whether we care to admit or not - and C# just does not feel as fashionable as it once did

(I'm a former C# dev, up until 2020)

• koyote

  today at 2:23 AM

  I personally can't think of an all-rounder language that is better than C#. It's fast, has great tooling, powerful, extremely productive for working with large code bases and runs 'anywhere'.

  JS has lost against TS which is basically C# for web (both designed by the same person) and Python is not really something you should build large applications with (execution speed + maintenance issues).

  What do you believe is the current language du jour?

• Merad

  today at 2:06 AM

  I've been using .Net for almost 20 years, professionally for half that time, and I feel like excitement and momentum in the community has only been increasing.

• recursivecaveat

  today at 2:15 AM

  It is definitely out of fashion, most directly in comparison to Go I suppose. It seems like they tried with .NET Core, but were not able to provide an appealing and coherent enough on-ramp. The ongoing death of native windows applications not helping either certainly.