Collection switch Expression

[MigratoryCoconuts]

Currently, switch expressions always match exactly one branch (the first one), and return the result from this branch. this is a proposal to add a new, switch-like statement, that matches any number of branches, and returns an IEnumerable containing the results.
In my mind, this could be a new keyword, like select.
I've come across a couple of places where this would really help me:

1. when converting from a type with a large number of boolean flags to a list. I'm working on role/permission code at the moment, and we need to be able to convert between a list of roles and a "permissions" object on the fly often. I've had to write code that looks like this: (enforcing brackets on even single-line if statements is part of our linter)

if (permissions.HasProvideSupport)
{
    roles.Add(Codes.Roles.ProvideSupport);
}

if (permissions.HasSubmit)
{
    roles.Add(Codes.Roles.Submitter);
}

if (permissions.HasReports)
{
    roles.Add(Codes.Roles.Reporting);
}

if (permissions.HasManageUsers)
{
    roles.Add(Codes.Roles.ManageUsers);
}

if (permissions.HasAdmin)
{
    roles.Add(Codes.Roles.Admin);
}

... etc
...

where I imagine It could be a lot cleaner like

codes.UnionWith(permissions select 
{
    { HasProvideSupport: true } => Codes.Roles.ProvideSupport,
    { HasSubmit: true } => Codes.Roles.Submitter,
    { HasReports: true } => Codes.Roles.Reporting,
    { HasManageUsers: true } => Codes.Roles.ManageUsers,
    { HasAdmin: true } => Codes.Roles.Admin,
    ... etc
});

this of course is an extremely simple example where we are just checking boolean fields, but the statement would allow any amount of pattern matching, in exactly the same way as the current switch statement. the same constraints on expression type would also apply.

2. when trying to convert an enumerable while throwing away mismatched entries. one extension function I have in quite a lot of my projects looks like

public delegate bool TryParse<TIn, TOut>(TIn input, out TOut output);

public static IEnumerable<TOut> TryConvertAndFilter<TIn, TOut>(this IEnumerable<TIn> sequence, TryParse<TIn, TOut> tryParse) {
    foreach (var elem in sequence) {
        if (tryParse(elem, out var converted)) {
            yield return converted;
        }
    }
}

which i then call like IEnumerable<int> ints = stringList.TryConvertAndFilter(int.TryParse). However, the same result could easily be achieved with the select statement, and no boilerplate:

var ints = stringList.SelectMany(s => s select { _ when int.TryParse(s, out int i) => i });

this example shows that this new select operator doesn't need an exhaustive match to work - if nothing matches, the IEnumerable returned is empty. this is a key difference from the switch operator.

the syntax itself is definitely up for argument - select is used elsewhere in the language and might be ambiguous. however, I feel like this would be a major boon in working with collections, which a lot of recent C# language updates have been focussed towards.

[KennethHoff]

I think inline spread elements is a more cohesive proposal. I.e. this;

List<int> ints =
[
    .. a ? [1] : [],
    .. b ? [2] : [],
];

Especially if we get (and I haven't seen a proposal for this) something like this - which is basically just taken straight out of JavaScript ( or, at least how JSX is sometimes written), basically a "short-circuiting operator"

List<int> ints =
[
    .. a && [1],
    .. b && [2], 
];

Given the first, more likely snippet, your code would be like this:

codes.UnionWith([
    permissions.HasProvideSupport ? [Codes.Roles.ProvideSupport] : [],
    permissions.HasSubmit ? [Codes.Roles.Submitter] : [],
// And so on
]);

It's not as clean, but in return you get a much more versatile feature.

[MigratoryCoconuts]

I've thought about this some more, and i think the trading of cleanness for versatility is exactly what the switch statement currently works to avoid. in a similar argument to jnm2's comment below, i truly think there is value in the cleanliness and readability of my proposal, regardless of the other ways it can currently be achieved. I truly don't think that a list of ternaries is a particularly valid counter to this proposal, especially because it leaves pattern-matching (a huge focus in this language recently) completely on the wayside.
I do appreciate you working with me to find other solutions to the issues I pointed out, but I also think that the proposal stands regardless. with pattern-matching and collections being major focuses in recent updates to C#, i think this syntax would fit perfectly, and allow me to keep writing modern code that fits in with the other code we are writing in C#12+

[jnm2]

The language currently provides this with great compatibility across collections in the form of:

codes.UnionWith([
    .. permissions.HasProvideSupport ? new[] { Codes.Roles.ProvideSupport } : [],
    .. permissions.HasSubmit ? new[] { Codes.Roles.Submitter } : [],
    .. permissions.HasReports ? new[] { Codes.Roles.Reporting } : [],
    .. permissions.HasManageUsers ? new[] { Codes.Roles.ManageUsers } : [],
    .. permissions.HasAdmin ? new[] { Codes.Roles.Admin } : [],
]);

[MigratoryCoconuts]

thank you both! I've been trained to be naturally suspicious of ternary statements, but this seems like a good place to use them. I don't necessarily think the ability to do what you pointed out invalidates this proposal, but it is a great alternative that I will probably use :)

[jnm2]

Another thing that has come up in the past is that the language isn't driven by linters restricting existing usages of the language. This is already really good:

if (permissions.HasProvideSupport) codes.Add(Codes.Roles.ProvideSupport);
if (permissions.HasSubmit) codes.Add(Codes.Roles.Submitter);
if (permissions.HasReports) codes.Add(Codes.Roles.Reporting);
if (permissions.HasManageUsers) codes.Add(Codes.Roles.ManageUsers);
if (permissions.HasAdmin) codes.Add(Codes.Roles.Admin);

[MigratoryCoconuts]

to be fair, any current switch statement can be written like this as well, but with else if instead of if. the existence of this syntax doesn't preclude a better, pattern-based syntax

[jnm2]

Agreed, point well taken. I would just avoid a point that comes down to "a linter is the reason why this example is cumbersome."

[dersia]

I like that idea a lot, I would just prefer map over select because it is mapping patterns to values... but then again we already have select in Linq 😔