Allow argument in default case switch

[Thaina]

Like case TYPE obj in pattern matching switch, I think we should be allowed default obj to get the value of switched object when it fall to default

var someDictionary = new Dictionary<string,object>();
////
switch(someDictionary["TT"])
{
    case null: return "";
    case string s: return s;
    case int i: return i.ToString();
    default obj: throw new Exception("Not support type : " + (obj?.GetType() ?? "null"));
}

The obj in this case would be the same type as the thing put into switch clause, in this case is object

[yaakov-h]

The var pattern already matches anything, i.e.:

switch(someDictionary["TT"])
{
    case null: return "";
    case string s: return s;
    case int i: return i.ToString();
    case var obj: throw new Exception("Not support type : " + (obj?.GetType().FullName ?? "null"));
}

[Thaina]

@yaakov-h Do case var get flow analysis in the same way as default ?

Are there really not any difference between case var and default ?

[PathogenDavid]

Yup, it does.

switch (someDictionary["TT"])
{
    case null: return "";
    case string s: return s;
    case int i: return i.ToString();
    case var obj: throw new Exception($"Unsupported type: {obj.GetType()}");
}

Console.WriteLine("This code is unreachable."); // CS0162: Unreachable code detected

---

Are there really not any difference between case var and default ?

From an IL perspective, the only difference is case var is that the object is stored in a local.

One difference is that case var doesn't cover the case null case, so you'd need to add it too if you weren't checking it already. (However, since the use case of case var is that you want to inspect the object, I'd assume you'd want to handle it being null in a sensible manner.)

[CyrusNajmabadi]

One difference is that case var doesn't cover the case null case

This is untrue. the 'var' pattern matches 'null'.

[PathogenDavid]

Oops, I accidentally had case object obj in SharpLab when I wrote that. Sorry for the misinformation, and thanks for the correction.

[CyrusNajmabadi]

No worries :)

[Thaina]

Thanks all

[gafter]

case var x: and default: are almost the same. Here are two differences:

1. The default case is always considered to be a last choice, where a case var x: matches everything and would override any later cases from being able to match.

2. The default case is always considered to be reachable, even if the other cases already handle all possible inputs. case var x:, on the other hand, would be an error if previous cases already handle everything.

[Thaina]

@gafter So should we still have this proposal as separate case from case var ?

[CyrusNajmabadi]

I would not. You can still get he behavior desired from default obj today. Just place the 'case var x' last if you care about '1'. And '2' will simply not you let write a redundant case, which seems fine. So there doesn't seem to be any real need for this proposal.

[Thaina]

@CyrusNajmabadi If the default one is the shortest logic to write I would place it on the top of switch

[CyrusNajmabadi]

so move it to the end. :) adding a full language feature just so you can put the final case of the switch at the top of the switch seems very unnecessary.

[Thaina]

@CyrusNajmabadi default is not always be the final case. switch might normally be written to handle many common case and has default as a guard. But also it could be written to handle exceptional case and has default as the common case and so it should be on top in some situation

[CyrusNajmabadi]

and so it should be on top

Then just rewrite it. Adding a language feature to support this exact coding pattern seems unnecessary.