Lasse R.H. Nielsen

One thing you can do today is: ``` extension on Set { bool operator >(T e) => contains(e); } ... case Set _ && > 1 && > 2: ......

Probably won't terminate for ``` abstract class C implements List {} abstract class D implements List {} ``` and doing **Up**(`C`, `D`). Not recursing with the same algorithm means that...

The first switch is not exhaustive because there is no specified way to exhaust integers. Exhausting integers by range exhaustion, like this example tries, is something that *could* be possible...

No, you cannot exhaust doubles using `` patterns, or any non-match-all pattern, because you cannot match NaN using any of the match types which work towards exhaustiveness. (Getting more an...

If we add a way to have statements inside expressions, we can indeed choose to either allow or disallow local control flow statements like`return` or `break`. I'd personally allow them....

I think that allowing *small* and *restricted* statements, but not the full power of statements, is always going to be just short of powerful enough for what people want. Might...

If we say that a `{statements;}` has a type and a value, then we must be able to infer the type. Which means passing in context types. And probably assigning...

Definitely a contrived example. I expect almost all possible reasonable programs to be uniquely parsable, and the test will be contrived because it's _obvious_ to a human reader what the...

Block/statement expressions "need" a delimiter mainly because statements can already contain expressions. If expressions can just contain statements, then we risk cycles in the grammar. A unique delimiter can make...

There are lots of ideas floating around here. The simplest is allowing `return`, `break`, `continue` and `rethrow` as expressions. That allows some of the uses people have for statements in...