One regret I have with conditional ref expressions is that the following compiles without a diagnostic:

cond ? ref a : ref b

Clearly the user meant to take a ref here yet they forgot the ref before cond hence ended up with a value. Guessing many devs have spent time wondering what was going wrong here.

Would not like to repeat that mistake here. Suggest diagnostics for the following scenarios:

1. If all arms of the switch have ref but the overall expression does not.
2. If there is disagreement in the arms about ref

You could(if it doesn't already exist) add an Analyzer for the ref expressions as well "while you're at it"(not that that's a good argument for a language decision)

Clearly Jared has a point here, 99% of the time you want the ref of the returned expression, so a warning is very reasonable.

Adding that warning for ref ternaries should probably be done in the future, but it's off the scope of this proposal. Probably a warning wave too, to avoid breaking existing code.

i would simply make it a requirement for switches. WE can retcon ternaries independent of this.

Added a simple advisory for causing a warning instead of an error that requires that the returned ref is directly used. If we settle on the error, I will update the spec accordingly.

Update, after some thought and discussion I noticed that:

int a = 4;
ref int b = ref a;
int c = ref a;
int d = a == b ? ref a : ref b;

• c yields error CS8171 - Cannot initialize a by-value variable with a reference
• d does not yield any errors and is completely legal, as if the value is immediately dereferenced

Edit: the above examples are not very linked with each other. The initialization of c is an invalid intention, whereas the initialization of d simply discards a reference that is returned from the expression's result. It would be equally as legal to initialize d to a or b without a reference. The only dissonance is the discarding of the reference from the ternary.

We should definitely strive for consistency with ref variables, and designing ref switch expressions should return an error if the value is immediately dereferenced.

As for the ref ternary expressions, it could be a breaking change, via either a warning or an error that immediately applies to existing code, hinting that it was definitely a mistake in the first place. Though discussing this one goes out of scope of this PR.

I'll prepare spec changes for this new approach on the error, would love some more input on this decision to make sure we cover this case elegantly.