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

[Erica Sadun]

The only deal breaker for me is enumeration completeness checking. default gives me "all other cases", but I could happily replace that with case _.

-- E

> On Dec 9, 2015, at 4:45 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Dec 9, 2015, at 3:24 PM, J. Charles N. M. <jcharles.nmbiada at gmail.com <mailto: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>
>> 
> 
>  _______________________________________________
> 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/0e46fb31/attachment.html>