Alejandro Serrano

Closed in favor of #3646

> I don't think we should choose to keep API compatibility and make a wrapper class around k.c.a impl. I think this is actually what we should do to keep...

> Instead of the `else if` syntax, I'd much prefer just allowing arbitrary Boolean expressions in when with subject. Unfortunately, this is not as easy. For example, if I write:...

> without the benefits of exhaustiveness checking Although this proposal doesn't concern with exhaustiveness checking, we are pretty confident that if we implement this in the Kotlin compiler, the exhaustiveness...

Indeed, in smaller examples it's arguable that the change is minimal, and as argued in the KEEP, the translation is also quite direct to non-subject version. However, this has the...

> I cannot swap the arguments of `&&` if that is possible logically Unfortunately this is also the case currently with Kotlin, as data flow analysis works left-to-right. For example,...

The KEEP has been updated with sections on [why `else` is needed in some places](https://github.com/Kotlin/KEEP/blob/guards/proposals/guards.md#the-need-for-else) and a [description of exhaustiveness checking](https://github.com/Kotlin/KEEP/blob/guards/proposals/guards.md#exhaustiveness-checking).

> Should the proposal ensure that less specific conditions should go after more specific ones? This should be covered in principle by the reachability analysis in the compiler.

We have preliminary results from our survey (which cannot be shared directly, as it contains some personal information). The comments, and the discussion that they've spawned within the Kotlin team,...

The KEEP has been merged. Thanks everybody for their comments and suggestions!