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

[Joe Groff]

> 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();
    }

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>