Allow null conditional (?.) operator on left hand side of assignment

[mrjvdveen]

Consider this code:

if (Foo is { })
{
  Foo.Bar = "value";
}

I suggest introducing the possibility to write this like so:
Foo?.Bar = "value";
Writing it like this, should do exactly the same as the first example. So if Foo is null, then the assignment never happens.

[Update(jcouv):] Detailed proposal write-up: #6045

[svick]

There has been a previous discussion about this at #1800, though that issue is now closed.

[Joe4evr]

And that issue was deemed to be a dupe of #34.

[svick]

@Joe4evr It was closed that way, but I'm not sure it was actually a duplicate. #34 is part of C# 8.0 and it doesn't let you do what's proposed here.

[Tom01098]

I dislike this because the whole line doesn't happen if the LHS is 'null', it is much clearer to wrap this in an if statement IMO.

[CyrusNajmabadi]

It makes sense to me, when you have expr?.moreexpr, the grammar and language is literally defiend where .moreexpr is simply a lower RHS node of the ? (the conditional access expression). So, if we allowed: expr?.name = whatever then that would just be a node like so:

      ?
     / \
expr     =
        / \
   .name   whatever

So, like any conditional access expression, this would naturally fall out as "evaluate what is before the ?. if it null, do not evaluate what is after".

Feels fine and normal to me. it's just something that didn't fall out with how we did the precedence for everything here.

[mrjvdveen]

I've had a brief discussion with @KathleenDollard at Techorama in the Netherlands two weeks ago about this feature. It is not a part of C# 8 right now and we both felt it deserved a feature request of it's own.

@Tom01098: I get your point. However I'm also allowed to write:
foo?.Bar();
This line will not execute if foo is null. In my view it would only be consistent to allow
foo?.Prop = 'val';

[YairHalberstadt]

@mrjvdveen
Can I suggest renaming this issue to "allow null conditional (?.) operator on left hand side of assignment"

[mrjvdveen]

@mrjvdveen
Can I suggest renaming this issue to "allow null conditional (?.) operator on left hand side of assignment"

Thanks for your input. I renamed this issue.

[DavidArno]

Having improved your title, would you mind removing the "With the introduction of nullable reference types in C# 8 in mind" line in your OP, please? The code, if (Foo is { }) is a use of pattern matching and the rest of your post relates to the null conditional operator. None of it is related to NRTs.

[mrjvdveen]

Having improved your title, would you mind removing the "With the introduction of nullable reference types in C# 8 in mind" line in your OP, please? The code, if (Foo is { }) is a use of pattern matching and the rest of your post relates to the null conditional operator. None of it is related to NRTs.

Thanks for your input. I have changed the OP.
The first line of code is a way of doing a check for a non null object. It is relevant to the code and is correct by construction.

[alrz]

I think this has been brought up a couple times before, in short, it comes down to permitting ?. as an lvalue

o?.Event += Handler;

[HaloFour]

#1106

[DavidArno]

@HaloFour, it's probably best to ignore #1106 though as it was completely derailed by the makeloft troll. Far better to have a new thread that restarts the discussion on the possible merits of allowing ?. in lvalues.

[HaloFour]

@DavidArno

There are other comments there as well. We shouldn't let one bad actor wreck an entire thread. Even if the conversation continues here I think it's good to link the two issues.

[mrjvdveen]

@HaloFour, I agree on having the link here. It documents the history of the discussion on this subject.

[Rekkonnect]

Would this also handle null conditional assignment on set-only properties?

The error in that code sample is only produced because, currently, the compiler expects that with ?. you're only trying to get a value, not assign.

Properties with setters should allow ?. assignment, regardless of whether they contain a getter or not.

[CyrusNajmabadi]

I'll champion this as well.

[Rekkonnect]

Does this proposal also handle the case of using the ?[ operator for indexing arrays, or other objects with custom indexers in the LHS?

[Xyncgas]

Is it escaping type safety? something must've gone wrong if you are looking for members in a variable that is null as a consumer. but if you are providing the value you can do this in generic and write once apply to all so it seems to me that it's escaping dealing with the consequences of null in consumer's side

it's like shorthand for try {foo.bar = 5} catch { } or

   #IgnoreTypeSafety
   foo.bar = 5
   #endIgnoreTypeSafety

regardless I still want this feature to be implemented because I want to be lazy and write unsafe code, what can possibly go wrong, at the end of the day I will be blamed for bugs anyways

[Rekkonnect]

It is not a shorthand for either of those cases. The null-conditional operator for any member access operator (., [) should behave like the following:

if (foo is not null)
   foo.bar = 5;

No exceptions involved, because they're too expensive. No type unsafety either, you always account for null when dealing with references.

something must've gone wrong if you are looking for members in a variable that is null as a consumer

Even with your nullability settings and your strong usage of the ! operator, you cannot (at least reliably) get rid of null checks. Whether something's gone wrong or not, it's not the compiler's duty to cleverly eliminate null checks. If this ever happens, it will be during JIT compilation, and I don't even know if it does so, let alone how frequently and reliably.

[Xyncgas]

Maybe we can get rid of null in c# by opt-in feature, instead of giving nullable to everything, and having variables points to nullptr they should have a pointer to a static object that's the default state. I feel annoyed when I forgot to check for null and things break during testing too, only if things were never null I can be happier, I understand I can also take a walk outside and stop returning null in new codes I write it isn't a big deal for me

[Rekkonnect]

This is just not happening. null will be part of the language since it's been since day one, and it's also useful in certain scenarios.

You can use the nullability tooling available since C# 8.0/.NET Core 3.1(?) and respect it like you personally desire. Other than that, if you know your values aren't null, you shouldn't care. That's a general development tip, to always properly track what values you're passing. null values aren't the only problematic ones.

[Xyncgas]

New rules ok
imagine you have the object be default instead of null, which I think microsoft made the decision too soon to say default is null for reference types, because it's gonna break when we change this behavior later and they saw this coming too people have been saying let's get rid of null and RUST did, but anyways I think it would be ideal to let default to actually be type T that lives as an static object in runtime and anytime you try to do something like ObjectA.b it's just not possible to be null because ObjectA by default has a reference to the default state of its type if you've never set it or forgot to

[Rekkonnect]

Such a breaking change is probably never going to happen. I like the idea of having a "default" static object, which from what I assume would have to be constructed by the default instance constructor that will be introduced for that feature. It will have to be triggered in some other way though, like T.default, since default(T) is already valid syntax, despite being simplified to default.

This discussion however should be made in the respective proposal.

[Haukinger]

I'd always prefer seeing that something's going wrong instead of having it going havoc silently. That's what null and NullReferenceException are for - notifying you that something gone awry.

If I have code that accepts optional parameters or values, that code has to check for null and react accordingly.
Also, if I have code that doen't accept optional parameters or values, that code, too, has to check for null just to be on the safe side and then react accordingly.

Also, if (value == null) and much more so value?. is a lot more concise than verbose alternatives like Nullable (i.e. if (value.HasValue) ... value.Value). Conciseness is all what ?. is about, mind you.

[Xyncgas]

@jnyrup

In your case I would expect it not work (by nothing happens) since the object isn't null but it's the property that wasn't able to be set

[Xyncgas]

Any Updates?

[CyrusNajmabadi]

@Xyncgas I've championed this.

[legistek]

I would love to see this!

[333fred]

I'm converting this issue to a discussion, as #6045 has the template and proposal.