[swift-evolution] Remove default case in switch-case
Erica Sadun
erica at ericasadun.com
Wed Dec 9 18:09:47 CST 2015
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>
More information about the swift-evolution
mailing list