Allow Discards in Tuple Assignment within Switch Expressions to Preserve Existing Property Values

[RanKarat]

Motivation

When using tuple assignment with switch expressions, there are scenarios where we might want to update only some of the properties, leaving the others untouched. Currently, we have to explicitly specify the existing value for the property that we don't want to change. Allowing discards (_) in this context would simplify the code and make the intent clear.

Example

Current code without the feature:

(Color, MainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], MainColor),
    2 => (colorsArr[0], colorsArr[1]),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

Proposed code with the feature:

(Color, MainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], _),  // MainColor keeps its current or default value
    2 => (colorsArr[0], colorsArr[1]),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

Benefits

• Increased code readability: The intent to keep the existing value for the property is made explicit.
• Reduced code verbosity: Avoids the need to re-specify existing values for properties that should not change.
• Improved maintainability: Simplifies the codebase and could potentially reduce bugs.

[theunrepentantgeek]

we might want to update only some of the properties, leaving the others untouched

Does this mean that property assignment doesn't occur?

Given that a property may have logic associated with setting the value, there's a very significant difference between assigning the current value of a property and eliding the assignment completely.

With the original (current form):

(Color, MainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], MainColor),
    2 => (colorsArr[0], colorsArr[1]),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

It's very clear that both Color and MainColor are always assigned - with any logic in the setters triggered as well.

With the proposed form:

(Color, MainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], _),  // MainColor keeps its current or default value
    2 => (colorsArr[0], colorsArr[1]),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

it's not clear whether the assignment happens.

That is, if the first branch of the switch is taken, does MainColor get assigned?

If MainColor is not assigned, there's a very subtle, but potentially significant behaviour difference.

If MainColor is assigned, this is inconsistent with the normal behaviour of a discard (_) , which means that nothing happens with the value.

With respect to your stated benefits:

Increased code readability: The intent to keep the existing value for the property is made explicit.

The intent to keep the existing value is visible in the current form, when the user writes MainColor.

Reduced code verbosity: Avoids the need to re-specify existing values for properties that should not change.

Reducing code verbosity isn't in itself a benefit, unless widely used. Forms such as => for expression bodied members are only useful because they are widely used and thus commonly encountered. A narrow use case like this would be rarely used and thus cryptic to most maintainers.

Improved maintainability: Simplifies the codebase and could potentially reduce bugs.

I think the reverse is true. It makes the code more complicatec and would most likley introduce subtle bugs.

[RanKarat]

t's not clear whether the assignment happens.

Thank you for your feedback. The intent behind using the discard (_) is precisely to indicate that no assignment should happen for MainColor in the first branch of the switch. In the proposed form, when the first branch is taken, MainColor does not get assigned, and this is by design. The use of _ in this context is to make it explicitly clear that MainColor remains unchanged.

[KennethHoff]

I think the concept of "Actually, just use the default value after all" is something that should be more general.

For example, I've started to always use required on all properties on practically all classes - the explicitness is so nice - but there are scenarios where I still want to have a default value, so it would be nice if I could for example do this:

class Person
{
	public required string FirstName { get; init; }
	public required string LastName { get; init; }
	public required Role Role { get; init; } = Role.Customer;
}

enum Role
{
	Unknown = 0,
	Customer = 1,
	VIP = 2,
}

var person = new Person
{
	FirstName = "Kenneth",
	LastName = "Hoff",
	Role = _,
}

[KennethHoff]

Yes, I have to resort to doing that, but it's not ideal because in most scenarios I want to set it, but in some others I want to use the defaults.

Sometimes I even add something like this:

class Person
{
	public static readonly Role DefaultRole = Role.Customer;	

	public required string FirstName { get; init; }
	public required string LastName { get; init; }
	public required Role Role { get; init; } = DefaultRole;
}

var person = new Person
{
	FirstName = "Kenneth",
	LastName = "Hoff",
	Role = Person.DefaultRole,
}

which is especially terrible.

[jnm2]

Why is { A = B, Role = _ } not strictly worse than { A = B }? (That is, what's the motivation for explicitly asserting that the property exists at compile time while the code Role = _ is a no-op at runtime?)

[KennethHoff]

If that's the entire story, then I agree - that's just bloat.

But it's not the whole story. Let's just say that in 99% of scenarios, I want you to be explicit about which Role you want(ergo, it's required). However, in these few scenarios I want the Role to be the default value. (I believe I could theoretically use a Pragma disable for this, but that sounds awful as well.

That said, my suggestion is a bad workaround for what I actually want, which is Factory methods w/ Object Initializers (#6602). That could also be used for for example JSON serialization:

var person = JsonSerializer.Serialize<Person>(json)
{
	Role = Role.Customer
}

Although, I believe the syntax I used above is currently legal so it'd have to be something else (Might be wrong)

[333fred]

I believe I could theoretically use a Pragma disable for this, but that sounds awful as well

You cannot.

[KennethHoff]

I believe I could theoretically use a Pragma disable for this, but that sounds awful as well

You cannot.

You can't pragma disable the required keyword? TIL 🫠

[DavidArno]

I very occasionally come across the sort of scenario you describe. My approach to avoiding setting a property to itself is to return a bool too:

(Color, mainColor. setMainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], default, false),
    2 => (colorsArr[0], colorsArr[1], true),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

if (setMainColor) MainColor = mainColor;

Your solution is shorter, but for me these scenarios are real edge cases, so the feature isn't really justified. Plus I'm not convinced that it results in simpler code: it's just terser in my view.

[RanKarat]

Thank you for sharing your perspective. I'd like to offer some insights:

1. I find the original code more intuitive and concise:

(Color, MainColor) = colorsArr.Length switch
{
    1 => (colorsArr[0], MainColor),
    2 => (colorsArr[0], colorsArr[1]),
    _ => throw new Exception("SnackbarColors can only have 2 colors")
};

It resonates more with my coding style and preferences.

2. In my experience, I frequently encounter scenarios where the switch expression is more fitting than if-else constructs or traditional switch statements. Therefore, I wouldn't classify it as an "edge case" in my use cases.

I appreciate the feedback and understand that everyone has their coding preferences. Let's continue the discussion with an open mind!