Skip to content

Latest commit

 

History

History
245 lines (200 loc) · 7.32 KB

null-conditional-assignment.md

File metadata and controls

245 lines (200 loc) · 7.32 KB

Null-conditional assignment

[!INCLUDESpecletdisclaimer]

Champion issue: #8677

Summary

Permits assignment to occur conditionally within a a?.b or a?[b] expression.

usingSystem;classC{publicobjectobj;}voidM(C?c){c?.obj=newobject();}
usingSystem;classC{publiceventActionE;}voidM(C?c){c?.E+=()=>{Console.WriteLine("handled event E");};}
voidM(object[]?arr){arr?[42]=newobject();}

Motivation

A variety of motivating use cases can be found in the championed issue. Major motivations include:

  1. Parity between properties and Set() methods.
  2. Attaching event handlers in UI code.

Detailed design

  • The right side of the assignment is only evaluated when the receiver of the conditional access is non-null.
// M() is only executed if 'a' is non-null.// note: the value of 'a.b' doesn't affect whether things are evaluated here.a?.b= M();
  • All forms of compound assignment are allowed.
a?.b-=M();// oka?.b+=M();// ok// etc.
  • If the result of the expression is used, the expression's type must be known to be of a value type or a reference type. This is consistent with existing behaviors on conditional accesses.
classC<T>{publicT?field;}voidM1<T>(C<T>?c,Tt){(c?.field= t).ToString();// error: 'T' cannot be made nullable.c?.field= t;// ok}
  • Conditional access expressions are still not lvalues, and it's still not allowed to e.g. take a ref to them.
M(refa?.b);// error
  • It is not allowed to ref-assign to a conditional access. The main reason for this is that the only way you would conditionally access a ref variable is a ref field, and ref structs are forbidden from being used in nullable value types. If a valid scenario for a conditional ref-assignment came up in the future, we could add support at that time.
refstructRS{publicrefintb;}voidM(RSa,refintx){a?.b=refx;// error: Operator '?' can't be applied to operand of type 'RS'.}
  • It's not possible to e.g. assign to conditional accesses through deconstruction assignment. We anticipate it will be rare for people to want to do this, and not a significant drawback to need to do it over multiple separate assignment expressions instead.
(a?.b,c?.d)=(x,y);// error
a?.b++;// error--a?.b;// error
  • This feature generally doesn't work when the receiver of the conditional access is a value type. This is because it will fall into one of the following two cases:
voidCase1(MyStructa)=>a?.b= c;// a?.b is not allowed when 'a' is of non-nullable value typevoidCase2(MyStruct?a)=>a?.b= c;// `a.Value` is not a variable, so there's no reasonable meaning to define for the assignment

readonly-setter-calls-on-non-variables.md proposes relaxing this, in which case we could define a reasonable behavior for a?.b = c, when a is a System.Nullable<T> and b is a property with a readonly setter.

Specification

The null conditional assignment grammar is defined as follows:

null_conditional_assignment : null_conditional_member_access assignment_operator expression : null_conditional_element_access assignment_operator expression

See §11.7.7 and §11.7.11 for reference.

When the null conditional assignment appears in an expression-statement, its semantics are as follows:

  • P?.A = B is equivalent to if (P is not null) P.A = B;, except that P is only evaluated once.
  • P?[A] = B is equivalent to if (P is not null) P[A] = B, except that P is only evaluated once.

Otherwise, its semantics are as follows:

  • P?.A = B is equivalent to (P is null) ? (T?)null : (P.A = B), where T is the result type of P.A = B, except that P is only evaluated once.
  • P?[A] = B is equivalent to (P is null) ? (T?)null : (P[A] = B), where T is the result type of P[A] = B, except that P is only evaluated once.

Implementation

The grammar in the standard currently doesn't correspond strongly to the syntax design used in the implementation. We expect that to remain the case after this feature is implemented. The syntax design in the implementation isn't expected to actually change--only the way it is used will change. For example:

graph TD; subgraph ConditionalAccessExpression whole[a?.b = c] end subgraph subgraph WhenNotNull whole-->whenNotNull[".b = c"]; whenNotNull-->.b; whenNotNull-->eq[=]; whenNotNull-->c; end subgraph OperatorToken whole-->?; end subgraph Expression whole-->a; end end
Loading

Complex examples

classC{refintM()=>/*...*/;}voidM1(C?c){c?.M()=42;// equivalent to:if(cis not null)c.M()=42;}int?M2(C?c){returnc?.M()=42;// equivalent to:returncisnull?(int?)null:c.M()=42;}
M(a?.b?.c= d);// equivalent to:M(aisnull?null:(a.bisnull?null:(a.b.c=d)));
returna?.b= c?.d= e?.f;// equivalent to:returna?.b=(c?.d= e?.f);// equivalent to:returnaisnull?null:(a.b=cisnull?null:(c.d=eisnull?null:e.f));}
a?.b??=c;// equivalent to:if(ais not null){if(a.bisnull){a.b=c;}}returna?.b??=c;// equivalent to:returnaisnull?null:a.bisnull?a.b=c:a.b;

Drawbacks

The choice to keep the assignment within the conditional access introduces some additional work for the IDE, which has many code paths which need to work backwards from an assignment to identifying the thing being assigned.

Alternatives

We could instead make the ?. syntactically a child of the =. This makes it so any handling of = expressions needs to become aware of the conditionality of the right side in the presence of ?. on the left. It also makes it so the structure of the syntax doesn't correspond as strongly to the semantics.

Unresolved questions

Design meetings

close