Pattern matching on boolean fields: shorter syntax for matching 'true'

[epa]

In pattern matching you can currently have

public struct HasBool
{
    public bool b;
    public static int Foo(object o)
    {
        return o switch
        {
            HasBool {b: true} => 5,
            _ => 6
        };
    }
}

I would like a shorter syntax for the b: true pattern match. If the field or property is a boolean, then you should be able to match it giving just the name, implying a test for true. So,

        return o switch
        {
            HasBool {b} => 5,
            _ => 6
        };

(The same pattern matching syntax should be available in switch statements as well as switch expressions.)

Often boolean fields or properties have a name which describes the condition. The shorter syntax would be particularly useful when matching several of these flags:

case MyClass { IsEnabled, IsLoaded, IsTasty, CountLegs: 4 } mc:

(I envisage that as a formal language proposal, the two tokens : true would be implicitly added if the pattern match consists of just a single field or property name and nothing more. That would then give a type error if you tried to specify this kind of match for a non-boolean field.)

[amis92]

My first thought: what about matching false?

Instinct says HasBool { !b } => 5; so match true by simply stating property name, match false by prefixing it with ! operator.

[julealgon]

I think Hasbool { not b } would be more aligned with pattern matching.

[333fred]

I like the idea, but it is unfortunately going to be ambiguous with list patterns: #3435. Given the latest LDM decisions on the syntax for that, this code would be ambiguous:

class C
{
    public bool ConstOrProperty => true;
    public int this[int index] => 1;
    public int Count { get; }
}

const int ConstOrProperty = 1;
_ = (new C()) is { ConstOrProperty };

[epa]

Could you explain what the issue is? I don't understand how ConstOrProperty is a problem if it's of boolean type. Can the type be used to disambiguate the syntax?

[333fred]

The issue is that it's ambiguous. Is that matching against the ConstOrProperty property for true, or is it matching against the first element of C using the ConstOrProperty constant as a constant pattern?

[333fred]

Perhaps forcing a : to indicate it is a property would remove ambiguity?

_ = (new C()) is { ConstOrProperty: }; // For sure a property

Maybe, but at first blush I'm not a huge fan of the trailing colon.

[epa]

Thanks, sorry I did not spot that ConstOrProperty was defined both as a field on the class and as a constant in scope of the pattern match. Personally, I'd be fine if it just gave a syntax error in that case, since a name collision between a boolean field and an integer constant is unlikely, and you can work around it by going back to the more verbose syntax. I agree it is a bit of a rough edge.

[333fred]

and you can work around it by going back to the more verbose syntax.

Only in one direction.

[Flutterish]

(I envisage that as a formal language proposal, the two tokens : true would be implicitly added if the pattern match consists of just a single field or property name and nothing more. That would then give a type error if you tried to specify this kind of match for a non-boolean field.)

Perhaps an implicit : not null as well for classes when just the name is specified?

[julealgon]

Very interesting that I found this from just yesterday... have been wanting to post this proposal for some time as well.

Today I got hit with another case where it would be much nicer to read if we had simplified pattern matching for boolean properties:

return fileResponse switch
{
	{ IsSuccessStatusCode: false, ReasonPhrase: var errorMessage, StatusCode: var statusCode } =>
		new UnableToDownloadFile(errorMessage, statusCode),

...

Would become:

return fileResponse switch
{
	{ not IsSuccessStatusCode, ReasonPhrase: var errorMessage, StatusCode: var statusCode } =>
		new UnableToDownloadFile(errorMessage, statusCode),

...

[HaloFour]

IMO it's not worth the reduction in clarity. The IDE could already note that the pattern applies to a bool property and offer true/false in autocomplete so it's not like the developer is required to type that out in entirety every time.

[julealgon]

... so it's not like the developer is required to type that out in entirety every time.

@HaloFour I don't see this as much of a "typing" problem, but a "readability" and "conciseness" one.

Allowing matches on the bool directly would be good for the same reasons as why it is good to check on bools directly.

Nobody does this:

if (request.IsSuccessStatusCode == true)
{
    ...
}

IMO it's not worth the reduction in clarity.

Do you have an alternative suggestion?

[HaloFour]

That's my point, I don't think it improves readability. I think it actively harms readability when used in a recursive property pattern against other properties. Given it already collides with the proposed syntax for list patterns I don't think there is a syntactic form that could be suggested that could both clearly eliminate that ambiguity as well as keep the conciseness you desire.

[alrz]

This reminds of the suggestion if (x is) to check for null. that's not ambigious either.

[julealgon]

I feel like we are actually missing a symbol to use for lists... kind of unfortunate. I understand though what I proposed does look strange.

Perhaps we should invent a new brace-like character and ask people to include it on keyboards 😆