[swift-evolution] Proposal: Remove the "fallthrough" keyword

[Dave Abrahams]

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" ;-)

> 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