Right. Both seem equally reasonable alternatives if a condition isn't fulfilled where I'd like to continue pattern matching. Why do you say one of these would be fair to disallow? On Mon, Jul 11, 2016 at 00:39 Erica Sadun <[email protected]> wrote:
> Because one says "consider the next case" and the other says "do not > consider the next case" > > On Jul 10, 2016, at 11:03 PM, Xiaodi Wu <[email protected]> wrote: > > I know how it works. Why would you say that it's reasonable to prohibit > fallthrough when continue is used? The difference between it and break is > that Swift chooses the latter to be implied, and obviously we cannot > prohibit break. > On Sun, Jul 10, 2016 at 23:51 Erica Sadun <[email protected]> wrote: > >> On Jul 10, 2016, at 10:34 PM, Xiaodi Wu <[email protected]> wrote: >> >> >> >> On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <[email protected]> >> wrote: >> >>> On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <[email protected]> wrote: >>> Given patterns A, B, C, and D, suppose a value x matches A, C, and D, >>> whereas another value y matches B and D, and a third value matches B and >>> C. When evaluating x, y, or z, which statements are executed in the >>> following switch statement? How many of these reach the default case? What >>> happens if I append `fallthrough` at the end of case D? What happens if I >>> move case B after case D? (Yes, I know it is possible to figure it out [my >>> understanding of the answer to the first question is appended below], but I >>> hope you'll agree with me that this is much more difficult to decipher than >>> any switch statement that's currently possible.) >>> >>> ``` >>> switch x /* or y, or z */ { >>> case A: >>> // ... >>> continue >>> case B: >>> // ... >>> if C ~= x /* or y, or z, whichever is switched over */ { >>> continue >>> } >>> fallthrough >>> >>> >>> I'd say it would be fair to disallow continue and fallthrough to occur >>> in the same clause >>> >> >> Why should `fallthrough` be prohibited but implicit `break` become >> mandatory in such a clause? If `continue` were to be implemented in this >> context, I'd want the full power of the keyword, including being allowed to >> `continue` conditionally, `continue` with different labels, and round out >> the case if no conditions are satisfied with either `fallthrough` or >> `break` (or, for that matter, `return`, etc.). >> >> >> I do not understand. `break` is already implicit unless no other code is >> used. >> >> case something: >> if condition { continue } >> // ends here. the compiler knows not to go forward and it's not an >> empty clause >> case somethingElse: >> >> `fallthrough` means "ignore the next case statement and execute its >> clause". >> >> -- E >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
