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

[Pierre Habouzit]

> 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.

that would be awesome.

> 
>> 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

the pattern I showed is really really pervasive in system programming code, especially because in that example below:

>> if some_value == .Refined && !validate(some_value) {
>> 	return NULL
>> }
>> handle_enum_value()


the “validate” is shifted to the right, which hides the essential thing you’re doing, which is the validation.
it is important to me to see the validation stand out and be one indent level away, and not arbitrarily pushed to the right.

it allows to read your code keeping your eyes aligned on the first columns of your text editor to get a sense of the flow of what is going on.

David’s example has this property and I find it very desireable.


>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/9cba0e16/attachment-0001.html>