Thanks Maurizio! On 8 Apr 2022, at 11:57, Maurizio Cimadamore <maurizio.cimadam...@oracle.com<mailto:maurizio.cimadam...@oracle.com>> wrote:
Hi Gavin, great work - some comments: * in section 6 on names there's no mention of whether pattern variables are matched in the `when` clause. This is covered in section 6.3.4? But maybe I misunderstand your point? * section 14.11.1, you say that a case element is "unrefined" if it has `when` with constant expression whose value is `true`. This is a bit ambiguous: I think what you want here is "evaluates to true", because I think you also want to cover "true || true" or "!!true", right? I think that's what you meant, but the word "value" is confusing, I think. This ambiguity is also present in the rule below when we say that two case label with same "value" are not permitted. Maybe all this is pre-existing, but I wonder it it could be worth clarifying. Point taken, but I followed the language of Chapter of JLS on Definite Assignment, e.g. in 16.1.1: "V is [un]assigned after any >>> constant expression (§15.29) whose value is true <<< when false.” * we define the concept of what it means for a case label to "support default" but we do not define what it means to "support null". The latter is also referred to in the list of checks for switch labels in 14.11.1 Yeah - I’m probably trying to be too clever here...let me try to clarify some of the language... * "If a switch label appears at the end of a switch block, it is a compile-time error if it consists of more than one case or default label." - not sure I get this? I mean, sure I can't have "case default: case default" - but the rest? E.g. can't I end a switch with "case 4: case 5: ..." ? Yikes - mistake! Thanks for spotting. * this sentence "A switch label that supports a unrefined pattern p dominates another switch label supporting a pattern q if p dominates q" is tricky - but I think correct; only labels w/o a "when" can dominate other labels, and pattern dominance doesn't care about "when", so you shold be good. * 10.3.2 and also the small example at the end of the definition of "executable switch" refer to the notion of "any" pattern - but that pattern is not defined It is defined at the end of 14.30.1, but it is (currently) a pattern that can’t be expressed, so is not in the grammar, but is a pattern that appears in the process of resolving a pattern (defined in 14.30.2). This is similar to the JLS treatment of intersection types, that don’t appear in the grammar, but are defined as types in Chapter 4. Thanks so much for these comments! Gavin
