> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > 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" ;-)
Cool by me. This does have the nice benefit over traditional 'goto' that each strand of spaghetti at least has a well-defined lexical scope, and a controlled way of passing state among scopes by pattern matching. -Joe > >> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution