on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote: >> On Dec 5, 2015, at 10:13 AM, David Owens II <david at owensd.io> wrote: >> >> Is there a reason we cannot use labelled case statements? >> >> switch some_value { >> case .REFINED: >> if !validate(some_value) { return NULL } >> fallthrough base >> >> base: case .BASE: >> handle_enum_value(); >> } >> >> At least this is explicit now. > > Yeah, maybe there's a more general language feature that could replace > 'fallthrough' here. Instead > of labelling cases, we could support a 'reswitch' statement that redispatches > the switch to the case > matching the operand: > > switch some_value { > case .REFINED: > if !validate(some_value) { return NULL } > reswitch .BASE > > case .BASE: > handle_enum_value(); > }
We should just call a spade a spade and spell that "goto" ;-) > That should be easy to peephole to a proper fallthrough in constant cases, > but would also nicely > generalize to applications like interpreters, where it's often desirable to > push the dispatch inline > into the logic for better pipelining. > > -Joe > >> >>> On Dec 5, 2015, at 10:04 AM, Vinicius Vendramini <vinivendra at gmail.com >>> <mailto:vinivendra at > gmail.com>> wrote: >>> >>> I understand there might be some cases in which the syntax provided >>> is indeed useful for experienced programmers writing their >>> code. However, in almost all the examples here, I had to struggle >>> to understand the logic behind the code. Not because it’s poorly >>> written... probably because this syntax may be used for many >>> different purposes, so it’s hard to get what exactly is the intent >>> behind each use. >>> >>> In Pierre’s latest example, for instance, it took me a few seconds >>> to understand what was going on. I know it’s a simplified case, but >>> it seems clearer to me to just write something like >>> >>> if some_value == .Refined && !validate(some_value) { >>> return NULL >>> } >>> handle_enum_value() >>> >>> More complex cases make for a better argument for `switch`es, >>> mainly because they avoid big `if` pyramids, but especially in >>> those I feel the resulting code is significantly harder to >>> understand. >>> >>>> On Dec 5, 2015, at 12:15 PM, Pierre Habouzit <phabouzit at apple.com >>>> <mailto:phabouzit at apple.com>> wrote: >>>> >>>> >>>>> On Dec 5, 2015, at 9:02 AM, Chris Lattner <clattner at apple.com >>>>> <mailto:clattner at apple.com>> wrote: >>>>> >>>>> On Dec 4, 2015, at 2:05 PM, jalkut at red-sweater.com <mailto:jalkut at >>>>> red-sweater.com> wrote: >>>>>> In the spirit of some other proposals that remove C or C++ style >>>>>> artifacts, what do folks think about the possibility of removing >>>>>> the "fallthrough" keyword from the language? >>>>> >>>>> I’m not making an argument either way, but I want to point >>>>> something out: there is a major difference between fallthrough vs >>>>> ++/c-style-for. To someone who doesn’t know them, the later are >>>>> "syntactic magic” with no reasonable way to decipher other than >>>>> looking them up somewhere. The former is an English word whose >>>>> meaning is obvious in context. >>>>> >>>>> All I’m saying is that to a reader of code, the “badness” of ++ >>>>> and c-style for loops is greater than the “badness" of >>>>> fallthrough. >>>> >>>> Given that Swift has the goal to also be a low level language, fallthrough >>>> is really useful for conciseness and readability. >>>> >>>> in system programming C, I find myself writing things like this very often: >>>> >>>> >>>> switch (some_value) { >>>> case ENUM_VALUE_REFINED: >>>> if (validate(some_value)) { >>>> return NULL; >>>> } >>>> /* fallthrough */ >>>> case ENUM_VALUE_BASE: >>>> handle_enum_value(); >>>> … >>>> } >>>> >>>> Where the swift equivalent would roughly be: >>>> >>>> switch some_value { >>>> case .REFINED: >>>> if !validate(some_value) { return NULL } >>>> fallthrough >>>> case .BASE: >>>> handle_enum_value(); >>>> } >>>> >>>> This is as readable as it gets and is a pattern that the libdispatch has >>>> in several places e.g. >>>> >>>> Of course, you cannot fall through to arbitrary cases, so things like this >>>> C code cannot be done in swift: >>>> >>>> switch (some_value) { >>>> case ENUM_VALUE_REFINED_1: >>>> if (validate(some_value)) { >>>> return NULL; >>>> } >>>> goto base_value; >>>> case ENUM_VALUE_REFINED_2: >>>> if (validate(some_value)) { >>>> return NULL; >>>> } >>>> goto base_value; >>>> >>>> case ENUM_VALUE_BASE: >>>> base_value: >>>> handle_enum_value(); >>>> … >>>> } >>>> >>>> >>>> cannot be written in swift, despite also being quite useful. >>>> >>>> Jumping between arbitrary points inside a switch is disgusting. jumping >>>> from label to label is useful and not harmful especially in swift where >>>> you can’t place code between the “switch” and the first case. >>>> >>>> -Pierre >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution at swift.org <mailto:swift-evolution at swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/193d117e/attachment.html> -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution