Remove default case in switch-case

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

···

On Dec 9, 2015, at 3:01 PM, Mustafa Yusuf via swift-evolution <swift-evolution@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.

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@swift.org> wrote:

On Dec 9, 2015, at 3:01 PM, Mustafa Yusuf via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

···

On Dec 9, 2015, at 3:24 PM, J. Charles N. M. <jcharles.nmbiada@gmail.com> wrote:

Le 10 déc. 2015 12:08 AM, "Jacob Bandes-Storch via swift-evolution" <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 9, 2015, at 3:01 PM, Mustafa Yusuf via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

On Dec 9, 2015, at 3:24 PM, J. Charles N. M. <jcharles.nmbiada@gmail.com <mailto:jcharles.nmbiada@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 9, 2015, at 3:01 PM, Mustafa Yusuf via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

I don’t have a strong feeling on this one way or the other, but I think it’s probably safe to say that the reason default is more familiar and widely used is because pretty much all the documentation I have seen does it that way, not because people like it better or because it is necessarily easy to understand. If the documentation was written using "case _" I think we would see that be the familiar and widely used variation.

FWIW, I think "default" is nicely expressive, and the _ construct always weirds me out just a little bit because while I understand it, it's not even a little bit intuitive to someone first learning a language.

As an aside, I'd think that this list, and the discussion and transparency that it provides is awesome. Insanely great, even.

Thanks!
Casey

···

On Dec 9, 2015, at 6:37 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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.

I don’t have a strong feeling on this one way or the other, but I think it’s probably safe to say that the reason default is more familiar and widely used is because pretty much all the documentation I have seen does it that way, not because people like it better or because it is necessarily easy to understand. If the documentation was written using "case _" I think we would see that be the familiar and widely used variation.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 for using "case _" instead of "default". It communicates programmer's intent clear and loud. Also it didn't occur to me to use it. :)

R+

···

Sent from my iPhone

On 10 Dec 2015, at 03:51, Casey Cady via swift-evolution <swift-evolution@swift.org> wrote:

FWIW, I think "default" is nicely expressive, and the _ construct always weirds me out just a little bit because while I understand it, it's not even a little bit intuitive to someone first learning a language.

As an aside, I'd think that this list, and the discussion and transparency that it provides is awesome. Insanely great, even.

Thanks!
Casey

On Dec 9, 2015, at 6:37 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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.

I don’t have a strong feeling on this one way or the other, but I think it’s probably safe to say that the reason default is more familiar and widely used is because pretty much all the documentation I have seen does it that way, not because people like it better or because it is necessarily easy to understand. If the documentation was written using "case _" I think we would see that be the familiar and widely used variation.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-1 from me.

- The meaning of “default” is more understandable and readable
- You can already use "case _" if you really want
- pretty much the entire existing Swift codebase would need to be changed if default was removed (and the existing code base will be much bigger by the time Swift 3 comes in).

I know backward compatibility isn’t considered to be a bar to accepting changes to Swift, but this does not mean it should be simply dismissed.

···

On 10 Dec 2015, at 20:06, Rudolf Adamkovic via swift-evolution <swift-evolution@swift.org> wrote:

+1 for using "case _" instead of "default". It communicates programmer's intent clear and loud. Also it didn't occur to me to use it. :)

R+

Sent from my iPhone

On 10 Dec 2015, at 03:51, Casey Cady via swift-evolution <swift-evolution@swift.org> wrote:

FWIW, I think "default" is nicely expressive, and the _ construct always weirds me out just a little bit because while I understand it, it's not even a little bit intuitive to someone first learning a language.

As an aside, I'd think that this list, and the discussion and transparency that it provides is awesome. Insanely great, even.

Thanks!
Casey

On Dec 9, 2015, at 6:37 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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.

I don’t have a strong feeling on this one way or the other, but I think it’s probably safe to say that the reason default is more familiar and widely used is because pretty much all the documentation I have seen does it that way, not because people like it better or because it is necessarily easy to understand. If the documentation was written using "case _" I think we would see that be the familiar and widely used variation.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution