[swift-evolution] Proposal: Remove the "fallthrough" keyword
Joe Groff
jgroff at apple.com
Fri Jan 20 14:45:37 CST 2017
> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>
>
> on Sat Dec 05 2015, jgroff at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list