Consider a shorthand for boolean fields

[nex3]

I've found myself fairly frequently needing to do pattern matches where I check boolean fields of the object I'm matching against. However, it's substantially more verbose to do that using the pattern matching syntax than a standard boolean expression one might use in an if/else: object.isState becomes Type(isState: true). Some of this will be mitigated by #2563, but I suggest also allowing Type(isState) as a shorthand for Type(isState: true). I think special-casing booleans makes sense given that pattern matching is an intrinsically boolean context.

[lrhn]

Grammatically it should work. All other object pattern field entries require a :, so not having one would be unique.
Presumably the names of boolean getters would make it easy to read.

It only works in refutable patterns, not assignment or declaration patterns, so we don't have to worry about someone just forgetting a colon in var Foo(bar, :baz) and working like bar: true instead of bar: var bar.
You have to write var bar to get that behavior (today).
It's still a failure mode, someone writing case Foo(bar): ... thinking it means :var bar. It's just slightly further from actually valid syntax. (And they should notice that the bar variable isn't introduced.)

The boolean field match would only work for object patterns. The only other real option is map patterns, and {"isFoo", "foo": var foo} doesn't read as well, and is unlikely to be type-safe.

That brings us back to type-safety. Is it OK to do List(first, ...) if it's a List<Object>? What if it's a List<String>?

If it's really just a shorthand for first: true, then it would be allowed, and we don't otherwise try to prevent you from doing tests that won't succeed (but the analyzer might tell you).
I'd still be willing to disallow the shorthand if the matched value type is not assignable to bool. It'll work, but I really want you to write the : true then, to show that you're ignoring any other value.

At least the meaning of the pattern true is true == $matchedValue, so we don't have to worry about other objects who consider themselves equal to ==.

With #2563, there might be more ambiguity. A (baz, qux: 42) pattern could be a record pattern where baz denotes a constant variable in scope, or the object pattern Foo(baz: true, qux: 42).
However we disambiguate in order to infer the Foo, it should likely not be based on the contents of the pattern, so the ambiguity is probably not a problem. We just decide to add the Foo. At most we lose a quick bail-out.

[rrousselGit]

I'm surprised I haven't made/seen this issue before. Big +1

I think it's one of the large pain points with the current pattern syntax. It's unnatural to do bool checks with : true/false when everything else in Dart tells you to not do that.

It makes the syntax odd compared to the rest of Dart

That brings us back to type safety. Is it OK to do List(first, ...) if it's a List<Object>? What if it's a List<String>?

If it's a List<bool>, yes. Otherwise no. Even List<bool?> shouldn't work in my opinion.

I'd base myself on what works with an if:

if (list.first) // works with List<bool> but not the rest

[mateusfccp]

Although I recon the problem may exist, I think the suggestion is actually very counter-intuitive.