[Draft proposal] Void branches

[jnm2]

Summary

Let a void branch of ?:, ??, or a switch expression skip the enclosing assignment, as a?.b = c does when a is null:

using System.Text.Json.Nodes;

JsonNode node = JsonNode.Parse("""{ "summary": "Hot" }""")!;

var forecast = new WeatherForecast
{
    TemperatureC = node["temperatureC"] is { } t ? (int)t : void, // keeps the default of 20
    Summary = (string?)node["summary"] ?? void,                   // sets "Hot"; keeps the default of "None" if missing
};

class WeatherForecast
{
    public int TemperatureC { get; init; } = 20;
    public string Summary { get; init; } = "None";
}

Motivation

Code that creates an object with new can set the object's init-only properties only in an object initializer, and an object initializer has no way to assign a member conditionally. So users can't set an init-only property on some paths and keep its default on the others. The System.Text.Json source generator and community generators work around this limitation with code that requires <AllowUnsafeBlocks>true</AllowUnsafeBlocks> in every consuming project that opts into unsafe evolution. A partner team has asked for this feature urgently, because the rollout of unsafe evolution will force more and more of these projects to set it. The final initializers proposal is also waiting on this one, because final initializers put more pressure on generators to set members inside an object initializer.

Users who write the initializer by hand copy the default into the other branch:

WeatherForecast Create(int? temperatureC, string? summary) => new WeatherForecast
{
    TemperatureC = temperatureC ?? 20, // copies the default
    Summary = summary ?? "None",       // copies the default
};


// Under this proposal:
WeatherForecast Create(int? temperatureC, string? summary) => new WeatherForecast
{
    TemperatureC = temperatureC ?? void,
    Summary = summary ?? void,
};

The copy goes stale when the type's author changes the default, and it can't follow a default that a constructor computes. Users have asked for a fix in conditionally set properties in object initializers and the other requests in Appendix B. LDM connected that discussion to conditional elements in collection expressions and expected "a feature to improve that for both collection literals and other types of initializers".

A generator usually can't copy the default, because it can be any expression and may be compiled into another assembly. So a generator that keeps defaults sets init-only properties after construction, through an UnsafeAccessor extern for each init accessor. Here is the output of the community PolyType generator for a class with three init-only properties, reformatted and with namespaces removed:

ParameterizedConstructor = static (ref SmallClassArgumentState<(string, int, string)> state) =>
{
    var obj = new Config();
    if (state.IsArgumentSet(0)) __SetAccessor_Config_Host(obj, state.Arguments.Item1);
    if (state.IsArgumentSet(1)) __SetAccessor_Config_Port(obj, state.Arguments.Item2);
    if (state.IsArgumentSet(2)) __SetAccessor_Config_ConnectionString(obj, state.Arguments.Item3!);
    return obj;
},
...
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "set_Host")]
private static extern void __SetAccessor_Config_Host(Config obj, string value);
...

With this proposal, the generator writes an object initializer instead:

ParameterizedConstructor = static (ref SmallClassArgumentState<(string, int, string)> state) => new Config
{
    Host = state.IsArgumentSet(0) ? state.Arguments.Item1 : void,
    Port = state.IsArgumentSet(1) ? state.Arguments.Item2 : void,
    ConnectionString = state.IsArgumentSet(2) ? state.Arguments.Item3! : void,
},

System.Text.Json first supported init-only properties by setting all of them in the initializer, so members missing from the payload lost their defaults. Setting only the members that are present takes one initializer per subset, or "$2^n$ constructor delegates" for $n$ init-only properties, according to the library's maintainer. System.Text.Json has since moved to UnsafeAccessor or reflection. The author of another serializer summed it up: "C# simply lacks the syntax for deserializers to emit C# code that honors default values of init accessor properties."

The AllowUnsafeBlocks requirement comes from the externs. Under unsafe evolution, every extern method must be marked unsafe or safe, and as proposed, both modifiers require AllowUnsafeBlocks. LDM gave source-generated code no exemption, so a generator's only other choice is reflection.

Final initializers affect every member that a generator sets, init-only or not. A final initializer runs at the end of the new expression, so in code that sets members afterward, it validates the defaults instead of the payload:

ConnectionSettings Create(int? port)
{
    var settings = new ConnectionSettings(); // the final initializer validates the default here
    if (port is { } p) settings.Port = p;    // never validated
    return settings;
}

// Under this proposal:
ConnectionSettings Create(int? port) =>
    new ConnectionSettings { Port = port ?? void }; // the final initializer validates the result

class ConnectionSettings
{
    public int Port { get; set; } = 443;

    init
    {
        if (Port is < 1 or > 65535) throw new InvalidOperationException("Port is out of range.");
    }
}

A generator can still validate the payload by creating the object without new, for example with Activator.CreateInstance, setting the members, and then running the final initializer itself. C# code can't invoke a final initializer, so the generator would call it through reflection or another UnsafeAccessor extern. With an extern, the AllowUnsafeBlocks requirement then applies to every type with a final initializer, whether or not it has init-only properties. The current design of final initializers supports generators "as long as they set members in an object initializer rather than after the constructor returns". With this proposal, a generator can set every optional member conditionally, inside one initializer.

Where a statement fits, an if statement is the right tool. But object initializers, with expressions, and field initializers have no statement position. The language already skips an assignment from inside an expression. In a null-conditional assignment a?.b = c(), c() isn't evaluated when a is null.

Detailed design

x = c ? a : void; has the same effect as if (c) x = a;, except that the target's receiver and index arguments are evaluated before c:

a[M()] = c ? b : void; // M() is called either way

The compiler emits a branch around the store, so the feature needs no runtime support or new metadata.

Where void can appear

void can be the second or third operand of ?:, the second operand of ??, or the expression of a switch expression arm. The conditional that contains it must be the right side of one of the following, directly, in parentheses, or through the branches of other conditionals:

• a simple, compound, or ref assignment;
• a member initializer in an object or with initializer, including an indexer initializer such as new A { [1] = c ? b : void };
• a local variable, field, or property initializer.

x = c1 ? a : c2 ? b : void;                 // ok
x = k switch { 1 => a, 2 => b, _ => void }; // ok
x = (c ? a : void) + 1;                     // error
M(c ? a : void);                            // error

We recommend limiting void to these positions (see How far void reaches) and requiring at least one branch with a value (see Assignments whose branches are all void). A lambda has its own body, so a void branch in a lambda needs an assignment inside that lambda. void followed by ( or * still begins a lambda with an explicit return type, as in void () => { }. A parenthesized void is an error, matching (throw e).

Types

A void branch has no type and converts implicitly to every type, through a new implicit void conversion modeled on the implicit throw conversion. So the other branches decide the type. n ?? void has type int when n is an int?, and s ?? void is not null when s is a string?, the same as with ?? throw e.

The value of a skipped assignment

We recommend that a skipped assignment yield the target's current value, so y = x = c ? a : void; leaves y equal to x on both paths (see Value of a skipped assignment). An assignment to a discard, or to a property or indexer without a get accessor, then has no value. It can still be a statement or a member initializer, as in _ = c ? Log() : void;, which calls Log only when c is true.

Compound, event, and ref assignments

In a compound assignment, a += c ? b : void means a = c ? a + b : void, except that a is evaluated once and its value is read before c. On the void branch, no operator is called, including a user-defined +=, and for an event, the add accessor isn't called.

A ref assignment can use a ref conditional with a void branch:

r = ref c ? ref a : void; // when c is false, r keeps referring to the same variable

A ref local declaration can't use one, because a ref local must be initialized.

Initializers

In an object or with initializer, a skipped member keeps the value that the constructor or the copy gave it. That makes with a direct way to apply a partial update:

ServerOptions Apply(ServerOptions options, ServerOptionsPatch patch) =>
    options with { Host = patch.Host ?? void, Port = patch.Port ?? void };

record ServerOptions(string Host, int Port);
record ServerOptionsPatch(string? Host, int? Port);

A local, field, or property initializer that takes the void branch leaves the variable unassigned. A field or property keeps its default value, and a local isn't definitely assigned afterward:

string? text = Environment.GetEnvironmentVariable("PORT");
int port = text is { } s ? int.Parse(s) : void;
Console.WriteLine(port); // error: port might be unassigned

A using declaration or using statement can't use void, because its variable could be unassigned when it's disposed.

Places where void is an error

• The whole right side, as in a = void;, because the assignment never happens.
• The initializer of a required member, because the member must be set during object initialization. LDM made the same choice for compound assignment in initializers.
• A let clause or an anonymous type member. Neither has an earlier value to keep, and void could suggest a type whose shape depends on a runtime condition. default covers a missing value there.
• A deconstructing assignment, because it isn't clear whether void should skip one element or the whole assignment. This can be allowed later.
• An expression tree, which has no node for a skipped assignment.

Definite assignment and nullable analysis

Both analyses treat the skipped path as though the assignment weren't there. So x = c ? a : void; doesn't make x definitely assigned, and afterward x may be null if it may have been null before or if a may be null.

Expansions

The same idea could skip other operations that consume a value. We don't propose these now. The core rules make void an error in each of these positions, so each could be added later without a break.

Skipping an invocation

This expansion would make M(c ? a : void); equivalent to if (c) M(a);. A void branch in an argument would skip the nearest enclosing invocation. The receiver and earlier arguments would be evaluated, but later arguments wouldn't, and the method wouldn't be called. The invocation would have no value, so it could only be a statement or the body of a lambda that returns void.

Users have asked for a way to skip a call when an argument is null, as M(?a) and as short-circuiting arguments. With this expansion, they would write M(a ?? void). It helps most in expression-bodied members and lambdas, and when several arguments are conditional, where M(a ?? void, b ?? void) replaces if (a is { } x && b is { } y) M(x, y);:

using System.Text.Json;

using var writer = new Utf8JsonWriter(Console.OpenStandardOutput());
writer.WriteString("summary", (string?)node["summary"] ?? void); // omits the property instead of writing null

The objection raised on M(?a) applies here as well: "some operator applied to an argument expression that alters the behavior of the parent expression". In its discussion of break and continue in arguments, LDM noted the same cost, but also that deciding before the call "leads to more ceremony and less locality of the code." We think a keyword in the branch is easier to spot than a ? prefix, but the objection is why invocations aren't part of the core. The expansion wouldn't apply to collection initializer elements, where a conditional spread is the better tool (see Conditional members and elements).

Other statements

throw e ?? void;, yield return x ?? void;, and return c ? a : void; could skip their statement, matching requests for throw?, null-conditional yield return, and return?. As with a = void;, return void; would be an error. These are statements, so an if already works there, and return c ? a : void; may read as if it always returns.

For await, this expansion would mean the language doesn't need await? after all. LDM approved null-conditional await for code like await? GetX()?.DoSomethingAsync();, which users could write as await (GetX()?.DoSomethingAsync() ?? void); instead. await? would be the first keyword made of a word and a symbol, and LDM's triage notes call it "an odd kind of keyword". A skipped await would have no value, so this form works only where the result is discarded, as in LDM's example.

Specification

Throughout this section, strikethrough indicates text being removed from the existing specification, and bold indicates text being added.

The baseline is the draft-v14 branch of the C# standard.

Expressions

§12.18 The null coalescing operator is updated as follows:

 null_coalescing_expression
     : conditional_or_expression
     | conditional_or_expression '??' null_coalescing_expression
     | throw_expression
+    | void_branch
     ;

A new subsection is added after §12.19 The throw expression operator:

The void branch

void_branch
    : 'void'
    ;

When the token void is followed by ( or *, it is not a void_branch.

Note: Such a void begins the return type of a lambda_expression. end note

A void_branch has no type. A void_branch is convertible to every type by an implicit void conversion.

A void_branch shall only occur in the following syntactic contexts:

• As the second or third operand of a conditional operator (?:).
• As the second operand of a null coalescing operator (??).
• As the switch_expression_arm_expression of a switch_expression_arm.

An expression is a skippable expression if it is:

• a conditional operator whose second or third operand is a void_branch or a skippable expression;
• a null coalescing operator whose second operand is a void_branch or a skippable expression;
• a switch_expression that has a switch_expression_arm_expression that is a void_branch or a skippable expression; or
• a parenthesized_expression whose expression is a skippable expression.

A skippable expression shall only occur as an operand or switch_expression_arm_expression that makes another expression skippable, or as one of the following, which is its skipped operation:

• The right operand of a simple_assignment, compound_assignment, or ref_assignment (§12.24).
• The initializer_value of a member_initializer (§12.8.17.2.2) whose initializer_target does not denote a required member (§15.7.1).
• The expression of an implicitly_typed_local_variable_declarator, or the local_variable_initializer of an explicitly_typed_local_variable_declarator, in a declaration that is not part of a using_statement or local_using_declaration (§13.14).
• The variable_initializer of a variable_declarator (§15.5.1) or of a property_initializer (§15.7.1).

The skipped operation of a void_branch is the skipped operation of the outermost skippable expression that contains it. It is a compile-time error for a void_branch to occur in an anonymous function that is converted to an expression tree type (§8.6).

A conditional operator always skips if its second and third operands are each a void_branch or a skippable expression that always skips. A switch_expression always skips if each of its switch_expression_arm_expressions is a void_branch or a skippable expression that always skips. A parenthesized_expression always skips if its expression always skips. It is a compile-time error for the skippable expression of a skipped operation to always skip.

At run-time, when a void_branch is evaluated, evaluation of its skipped operation ends. No value is converted, no operator is applied, no set, add, or remove accessor is invoked, and nothing is stored. A local variable, field, or property whose declarator or initializer is the skipped operation is not assigned. If the result of a skipped simple_assignment is used, it is the value of the left operand, obtained by invoking the get accessor when the left operand is a property or indexer access, with the instance expression and argument list already evaluated. If the result of a skipped compound_assignment is used, it is the value of the left operand that was obtained before the right operand was evaluated. The result of a skipped ref_assignment is its left operand, which continues to reference the variable it referenced before.

§12.21 Conditional operator is updated as follows:

 conditional_expression
     : null_coalescing_expression
     | null_coalescing_expression '?' expression ':' expression
     | null_coalescing_expression '?' 'ref' variable_reference ':'
       'ref' variable_reference
+    | null_coalescing_expression '?' 'ref' variable_reference ':' void_branch
+    | null_coalescing_expression '?' void_branch ':' 'ref' variable_reference
     ;

If ref is present and neither the second nor the third operand is a void_branch:

[…]

If ref is present and one of the second and third operands is a void_branch, the type of the result is the type of the other operand's variable_reference, and the result is a variable reference, which is writeable if that variable_reference is writeable.

§12.2.1 General is updated as follows:

• Nothing. This occurs when the expression is an invocation of a method with a return type of void, or a simple_assignment whose right operand is a skippable expression (The void branch) and whose left operand is a discard or a property or indexer access with no get accessor. An expression classified as nothing is only valid in the context of a statement_expression (§13.7) or as the body of a lambda_expression (§12.22).

[…]

• A throw expression, which may be used in several contexts to throw an exception in an expression. A throw expression may be converted by an implicit conversion to any type.
• A void branch, which may be used in several contexts to skip an assignment. A void branch may be converted by an implicit conversion to any type.

Conversions

§10.2.1 General is updated as follows:

• Implicit throw conversions (§10.2.17)
• Implicit void conversions (Implicit void conversions)

A new subsection is added after §10.2.17 Implicit throw conversions:

Implicit void conversions

While a void_branch does not have a type, it may be implicitly converted to any type.

Definite assignment

§9.4.4.25 Simple and deconstructing assignment expressions is updated as follows:

• If v is an assignment target of expr_lhs and expr_rhs is not a skippable expression, then the definite-assignment state of v after expr is definitely assigned. Otherwise, if the assignment occurs within the instance constructor of a struct type, and v is the hidden backing field of an automatically implemented property P on the instance being constructed, and a property access designating P is an assignment target of expr_lhs, and expr_rhs is not a skippable expression, then the definite-assignment state of v after expr is definitely assigned. Otherwise, the definite-assignment state of v after expr is the same as the definite-assignment state of v after expr_rhs.

A new subsection is added after §9.4.4.32 Throw expressions:

Void branches

For an expression expr that is a void_branch, the definite assignment state of v after expr is the same as the state of v before expr.

Drawbacks

Readers must check every branch to know whether an assignment happens, and a void branch can sit deep in a chain of conditionals. LDM weighed the same cost for null-conditional assignment, when a few members' "first read was that c() would be executed regardless of whether a was null", and accepted it. A void branch is further from the target than ?. is, so the skip is easier to miss. Users might possibly learn the forms that yield clarity nonetheless, as they do with ?? throw, by organizing the code so that it doesn't bury the lede.

void gains a meaning as an expression. Users have also asked for void as a type with a value, for use in generics. If LDM sees value in both, potential conflicts between them may need to be investigated.

The specification gains a second typeless operand beside throw expressions, with its own conversion and placement rules.

Alternatives

Do nothing

Generators keep setting members after construction. Once unsafe evolution and final initializers ship, their consumers need AllowUnsafeBlocks for every type that has init-only properties or a final initializer, unless the generator switches to reflection. Users who write initializers by hand keep copying defaults.

Conditional members and elements

A conditional member initializer such as new X { InitMember = if (cond) expr } has the same effect in initializers. It's special-cased to initializers and less widely useful, because it doesn't help assignments in statements, ??, or switch arms. The same syntax would allow [a, if (cond) b, c] or new List<T> { a, if (cond) b, c }, as Dart's collection if does. But the condition must be repeated for each element added under it, which [a, .. cond ? [b, c] : [], d] avoids. That spread is listed as future work for immediately enumerated collection expressions, and today it needs new[] { b, c }.

A when clause

A suggestion on the initializer discussion was B = b when readB, which resembles statement modifiers in Ruby and Perl. The value comes before the condition, so a pattern can't declare the variable that the value uses, as is { } t ? t : void does. We prefer void.

A keyword for "no change"

Requests have used _, value, and none in place of the void branch. _ is a discard and an identifier, value is a contextual keyword and a common identifier, and none would be a new keyword. void is already reserved and already means "no value".

Open questions

How far void reaches

A narrow rule allows void only in branch positions: a branch of a ?:, ??, or switch expression that is the assignment's right side, or that is itself in a branch position. Such expressions nest to any depth, but void can't reach the assignment through a condition, a switch expression's input, the left side of ??, or any other operand. A broader rule would let a void branch anywhere in the right side skip the whole assignment, as an earlier "poisonous null" idea did for arguments:

x = c1 ? k switch { 1 => a, _ => c2 ? b : void } : void; // 1: ok, 2: ok
x = (c ? a : void) ? b : d;                              // 1: error, 2: skips the assignment
x = (c ? a : void) + 1;                                  // 1: error, 2: skips the assignment
x = M(c ? a : void);                                     // 1: error, 2: skips the call and the assignment

Shall void be limited to branch positions, or allowed anywhere in the right side within the same body?

1. Branch positions only, at any depth. The skipped assignment is always the one whose right side is reached through branches alone, and an argument stays free to skip an invocation if that expansion is added. The rule can be relaxed later.
2. Anywhere in the right side. One rule covers more code, but readers must scan the whole right side to know whether the assignment happens, and a void in an argument would skip the assignment instead of the call, which rules out the invocation expansion.

Recommendation: Branch positions only, because the skip stays next to the code that causes it.

Value of a skipped assignment

var y = (x = c ? a : void);

What is the value of an assignment when its void branch is taken?

1. The target's current value. y equals x on both paths, and the type is the target's type. A discard, or a property or indexer without a get accessor, makes the assignment valueless. When the value is used, a simple assignment calls the get accessor on the skipped path, while the assigned path yields the right side without calling it.
2. default of the nullable target type, which matches a?.b = c when a is null. The assignment's type becomes T?, so y can't hold x's value on the skipped path.
3. No value whenever the right side can skip. It's the simplest, and either other option could be added later without a break.

Recommendation: The target's current value, because chained assignments keep the target's type and value on both paths.

Assignments whose branches are all void

x = c ? void : void;
x = k switch { 1 => void, _ => void };

Shall an assignment whose branches are all void be an error?

1. Error. The assignment never stores, and the conditional has no type. The rule can be relaxed later.
2. Allowed, evaluating the condition and skipping. Code generators that build arms mechanically wouldn't need a special case.

Recommendation: Error, because the code can only be a mistake or a long way to write _ = c;.

Appendix A: Precedent in other languages

We found no language in which a branch of a conditional cancels the enclosing assignment. The closest constructs fall into three groups.

Assignments skipped when the receiver is null:

• Swift optional chaining: "none of the code on the right-hand side of the = operator is evaluated".
• Kotlin safe calls: "the assignment is skipped, and the expression on the right is not evaluated at all".
• JavaScript optional chaining assignment, a Stage 1 proposal.

Members or elements omitted from a literal by a condition:

• Jsonnet conditional fields: [if c then "name"]: value.
• JavaScript conditional spread of properties: ...(c && { name: value }).
• Dart if elements and null-aware elements: key: ?value in a map literal omits the entry when value is null.
• Swift result builders: if without else inside a builder body.

Statements with a trailing condition:

• Ruby modifier if and Perl statement modifiers: x = a if c.

Appendix B: Requests

Counts are current totals across each row's threads. Upvotes include each discussion author's own, and reactions are on the opening post. The same user may have both upvoted and reacted.

Asks for	Requests	Upvotes, 👍, ❤️	👎, 😕
Conditionally set members in an initializer	#5588, #7413, #10263, issue #6117	31	0
A conditional operator without else	#197, #9128	16	31
Assign only if the value isn't null	#7560, #9660, #9351, #4147	18	12
Skip a call when an argument is null	#433, #444, issue dotnet/roslyn#5961	3	2
Skip a yield return, throw, or return	#5063, #1140, #9773, #6345, #8081	27	31
Generated deserializers that set init-only members and keep their defaults	issues dotnet/runtime#58770, dotnet/runtime#84484	50	0

[tannergooding]

-- just reiterating some things I said on Discord

The main problem I have with void is it feels like its abusing the type and in systems where () (unit) and void are interchangeable, it is typically straight up illegal, type unsafe, or means something else

I'd think a discard would be "clearer" in that case; i.e. Summary = cond ? 5 : _. While it could be confused for a few different meaning, you can at least describe it as discarding the assignment and so it becomes a nop (alternative views of x = _ could be that it "discards x" and so x becomes "dead", "disposed", etc)

I also prefer Ruby's approach of Summary = 5 if cond and could see that being a general pattern (or when/where instead of if) to using void; or even a general if (cond) { Summary = 5 } and just allowing statements in block initializers generally.

This in general isn't supper common in languages outside of conditional null assignment, which we already have.

[jnm2]

Maybe this will be the language version where we sink _ identifiers! 😁

For the = 5 if cond idea, this goes against C#'s left to right lexical evaluation order which has been pivotal in deciding how features like collection expressions work. It's also truly awkward when you're doing any of the examples in the above which would all require using a variable before it's been declared.

[qrli]

In a non-functional eye, my first feeling is that void is a type while here the proposal uses it as a value. Discard _ also came into my mind, as it is a value, and a value to be discarded.

I'd think _ is OK even when it may be an identifier, as generators can be sure not to use it as an identifier.

[sator-imaging]

(I like ?? nop to clearly express "do nothing")

[En3Tho]

My problem with this is that void on the right side controls what is going on the left side. E.g. it almost feels like it needs a different operator e.g. a =?? nullable or k =?? v switch { 1 => 2, 2, = 3, _ => null } and operator somehow feels more understandable to me.

void version is also quite verbose and requires you to spam that keyword everywhere.

I also think that it is trying to solve a specific problem and maybe some kind of general lightweight symbol-macro options would be more valuable to explore? We could end up with something like TryAssign(foo.Property, expr) or potentially with other interesting constructs.

P.S. I'm all up for sinking _ identifiers regardless of any other features :D

[qrli]

Exactly. The most logical thing is a conditional assignment operator.
However, after reading the OP, I feel that would be almost the same thing as = if (condition) value mentioned in the proposal. Considering C# already has a throw ex expression which can escape from assignment, I feel OK with a new expression way of escaping.

[CyrusNajmabadi]

I don't have a problem with void in the right side. I don't want to make this specific to assignment. After all there are lots of places without an assignment.

[CyrusNajmabadi]

I like void , but could also see _. I was surprised to not see this allowed in a collection initializer/expression as a way to avoid adding an item if a condition doesn't hold.

One reason I prefer void is simply that there is no ambiguity ever if we see it. Unlike _ which could be an identifier.

[jnm2]

The reason I didn't spec for collection expressions is that we can already do the same thing but in a more effective way that handles multiple elements at a time.
[a, .. cond ? [a, b] : [], .. c]
Versus:
[a, cond ? a : void, cond ? b : void, .. c]

It's pretty much a tie for the single-item case.

[jnm2]

And the reason I didn't give an example for collection initializers is because we have noted in passing during past meetings that we are much less interested in adding new expressiveness to those now that we have collection expressions. I think it would make sense and be consistent, but it's not a driving case.

[CyrusNajmabadi]

Note: for completeness/consistency, I would like conditional and switch to always be considered together.

So having a switch { b => void } work would be desirable to me.

[SolalPirelli]

If the goal is to let callers set either a specific value or the default value, perhaps default syntax should be extended to allow referring to properties? Summary = someCondition ? 42 : default(WeatherForecast.Summary).

[Richiban]

The problem is very real; what alternative syntaxes have been considered?

Would a limited statement syntax inside an object initialiser work?

E.g.

var forecast = new WeatherForecast
{
    if ( node["temperatureC"] is { } t)
    {
        TemperatureC = (int)t;
    }
    Summary = "..."
};

[CyrusNajmabadi]

So, i'm generally opposed to this being specific to object-initializer. If we have this for object-initializer, then i would expect it to work for collection-initializer as well. And if it works for collection-initializers, i would expect it work for collection-expressions. So i'd prefer any syntax we come up with work uniformly well for all 3 scenarios.

[jkotas]

I think if is the most natural way to express the intent of what this feature is trying to achieve. This example reads best to me out of all ideas shared here so far.

Is it possible to tweak the idea to work for collections too by moving if to be part of the expression? if would be only allowed before the value to use for the initialization, it would not be allowed inside the expression. Something like:

var forecast = new WeatherForecast
{
    TemperatureC = if (node["temperatureC"] is { } t) (int)t,
    Summary = "..."
};

List<string> names = ["Alice", if (bobIsHere) "Bob", "Charlie"];

[MattParkerDev]

Obviously a much more involved change, but would this be nicely solved with 'all statements are expressions', a la rust?

[CyrusNajmabadi]

I'd be opposed to if entirely because if we have it, we should then have if (a) e1 else e2. And if we have that, then we have redundancy between it and the existing conditional expression a ? b : c. I want to steer well clear away from if because i think it just introduces too much inconsistency.

when, on the other hand works well, as we already use it in the language in 3 cases to say do this if true, without any provision on what it should do when false.

[jkotas]

Obviously a much more involved change, but would this be nicely solved with 'all statements are expressions', a la rust?

I do not think so. Rust cannot express what we are trying to achieve here. Rust's "all statements are expressions" do not allow expression value to be void some of the time. We would still need to introduce the void value and deal with the fallout of propagating the void value and erasing its assignments. This fallout looks far from pretty..

[timcassell]

I don't like the skipping invocation syntax. If anything, I would expect that to select the optional parameter's default value.

M(c ? a : void); // a or 42

void M(int x = 42) { }

[timcassell]

Then the intuition becomes the value is not passed, not the invocation is skipped. It just so happens that with C# default parameters, not passing a value actually uses the default value. But it could also mean it uses another overload, like what @IS4Code was saying.

[jnm2]

And if that is generally a point of confusion, it is significant points against doing anything in this area from my perspective.

[UniqeId6542]

Would break/continue make sense here?
break: don't call the method
continue: don't pass in the value

I'd suggest break/default, but I don't know how to differentiate "default of data type" vs "default of parameter"

[IS4Code]

You would learn that the return does not happen, not that the return returns a default value.

I did not give much thought to it before but return void; feels very awkward not to at least share the effect of return;.

[AartBluestoke]

You would learn that the return does not happen, not that the return returns a default value.

I did not give much thought to it before but return void; feels very awkward not to at least share the effect of return;.

in some ways ' void' becomes conceptually a different operator precedence to '?? `

return a ?? void it is a request to do one of (return a) OR void

which is subtly different from the normal intuitive understanding of

return a ?? foo which does one of (return a) OR (return foo)

[colejohnson66]

The idea that a void somewhere down the right of the line can just make the whole expression null and void (pun intended), I don't like. I am on board with the concept of conditional execution, but M(a ? 42 : void) eliding the invocation doesn't sit right with me.

[jnm2]

Great feedback! Just curious, would any proposal for skipping an invocation based on a contained parameter be acceptable? I think M(?a, ?b); has been requested to skip the call if either a or b is null for instance, and the current proposal has this as M(a ?? void, b ?? void);.

[colejohnson66]

I'm not sure. Maybe I'll warm up to it, but my first glance is just "no". However, that's also based on me not having any off-the-top-of-my-head uses. I'm sure if it's implemented, I'd find some places in my code bases that fit it. That has happened with other features.

I will echo another comment for a ? 42 : _ to use the method-declared default value. Right now, you need to do a ? M(42) : M(). But that's unrelated.

[stepanbenes]

At first I thought this might be the mythical never type. But it is not. Although this proposal solves a real problem, it also takes C# from its path to become more functional language back to its imperative origins. void keyword is a good choice, it destroys every expression it touches.

[jnm2]

For reference, the never/bottom type indicates "compiler vouches that execution can never reach this point." #8603

[aelghoneimy]

I think this proposal might also fix/enhance the throw issue.

using System.Diagnostics.CodeAnalysis;

[DoesNotReturn]
public void ThrowNotFound(this ValidationMessage message) => throw new NotFoundException(message);

// somewhere else
var resource = await GetResource(id) ?? M.E12.ThrowNotFound(); // ERROR: Operator '??' cannot be applied to operands of type '...' and void

The above won't work because the null coalescing doesn't work with void returns, however the ThrowNotFound method clearly does not return.

[jnm2]

The proposal could be extended in this way, but currently this would be out of scope.

The above won't work because the null coalescing doesn't work with void returns,

The reason is stated slightly differently: DoesNotReturn and DoesNotReturnWhen are not compiler annotations about execution flow, only about nullability. They aren't airtight because what they are based on is nullability annotations which are themselves not airtight. Its okay for them not to be airtight if what is downstream of the decision is also nullability analysis. But if what is downstream is execution flow analysis, the stakes are much higher.

A feature which would provide an airtight declaration would be for example #8603.

[CyrusNajmabadi]

Yes. FOr that, i'd want a feature like public throw IAlwaysThrow() => throw new ...(); which then becomes part of the real contract of an api.

[UniqeId6542]

Could you add to Drawbacks how it might have confusion with "Switch expression as a statement expression"?
#2632
#5951

A switch expression in the future might allow calling a method that returns void. That void "return" might get confused with the void_branch - for how people understand the language.