[swift-evolution] Remove default case in switch-case

Chris Lattner clattner at apple.com
Wed Dec 9 17:45:57 CST 2015


On Dec 9, 2015, at 3:24 PM, J. Charles N. M. <jcharles.nmbiada at gmail.com> wrote:
> I agree, the default case has no interest since _ is more "swift”.
> 
I don’t think I expressed what I meant to.  I’ll try again:

1. The “case _” syntax already works and yet we have “default” anyways.
2. This is for a reason.  It is more readable and familiar.  
3. “default” is completely different than ++/— and c-style-for. Someone unfamiliar with it won’t look at it and be puzzled.
4. People use “default” all the time, making it dissimilar to ++, c-style-for, and fallthrough.
5. It is a redundancy in the language, and I agree that redundancy needs to be justified.

In terms of justifying/defending keeping default, I’ll point out two arguments:

1) We have had default and “case _” ever since Swift has been public.  If you look at bodies of existing swift code, they almost unanimously use “default” instead of “case _”.  This argues that default is more familiar and more widely used.  It isn’t some legacy barnacle on the side that people generally ignore.

2) This redundancy is precedented even in non-C-family languages like Haskell.  Haskell’s pattern matching works similarly to Swifts (really, swifts works similarly to Haskell’s :-), and even Haskell uses “otherwise” [a] to serve the purposes of “default” in swift.  While it is true that people could use “| True = 42” in Haskell, they almost always use "| otherwise = 42”.  I don’t think this is an accident, this reflects on the readability difference and the intentionality difference.  

-Chris

[a] Yes, I know that otherwise isn’t a keyword in Haskell, its a constant in the standard prelude.

> Le 10 déc. 2015 12:08 AM, "Jacob Bandes-Storch via swift-evolution" <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
> Sounds like the team/community has already shown that similarity with C isn't a priority that overrides clarity/simplicity in the language. Thus, +1
> 
> On Wed, Dec 9, 2015 at 3:06 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Dec 9, 2015, at 3:01 PM, Mustafa Yusuf via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> Hello all. In switch statements in swift if all the possible cases aren't covered we have to supply a default case.
>> 
>>     let number = 10
>> 
>>     switch number {
>>     case 10: print("yay")
>>     case 12: print("close")
>>     default: print("try again")
>>     }
>> 
>> My proposal is replace it with the "case _:".
>> 
>>     let number = 10
>> 
>>     switch number {
>>     case 10: print("yay")
>>     case 12: print("close")
>>     case _: print("try again")
>>     }
>> 
>> Since underscore in swift means "whatever I don't care" it suits here better than "default". Correct me If I am wrong but this is the only use for "default" keyword in swift I guess. So we can completely remove "default" keyword from the language.
>> 
> 
> FWIW, this is already supported.  We *also* support default for clarity of code / because it reads better, and for similarly with the (extended) C family of languages.
> 
> -Chris
> 
> 
> 
> _______________________________________________
> 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/20151209/96af6f91/attachment.html>


More information about the swift-evolution mailing list