Switch statement using blocks for conditions


(Marco Scannadinari) #1

Hi,

I found it odd that the `label:` style is used for switch-case conditions,
considering that Swift does not have implicit fallthrough. To me the label
style only makes sense if you think of conditions essentially as labels for
a goto statement, which implies fallthrough.

Personally I think this syntax would make more sense:

switch condition {
  case 1 {
    //
  }

  case 2 {
    //
  }
}

This is how Rust implements match, although it is an expression so it
especially applies to that context. Nonetheless I think the above syntax
not only looks a lot nicer but makes more sense, especially since the
current syntax is the only instance where Python-style colons and
indentation are used for designating sections of code rather than braces.

Thoughts?

-Marco


(Xiaodi Wu) #2

Hi Marco,

This idea has already been discussed on this list; however, source-breaking
changes require "extreme" justification and this particular idea has not
been found to provide obvious benefit. Moreover, Swift cases allow
fallthrough, which is less explicable when you surround each case with
braces.

The focus of this phase of Swift Evolution is listed on the GitHub site and
is generally clustered around ABI stability and completing generics.

Cheers,

Xiaodi

···

On Fri, Dec 23, 2016 at 07:04 Marco Scannadinari via swift-evolution < swift-evolution@swift.org> wrote:

Hi,

I found it odd that the `label:` style is used for switch-case conditions,
considering that Swift does not have implicit fallthrough. To me the label
style only makes sense if you think of conditions essentially as labels for
a goto statement, which implies fallthrough.

Personally I think this syntax would make more sense:

switch condition {
  case 1 {
    //
  }

  case 2 {
    //
  }
}

This is how Rust implements match, although it is an expression so it
especially applies to that context. Nonetheless I think the above syntax
not only looks a lot nicer but makes more sense, especially since the
current syntax is the only instance where Python-style colons and
indentation are used for designating sections of code rather than braces.

Thoughts?

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


(Derrick Ho) #3

Can you not write this?

switch condition {
case 1: do {
//
}

case 2: do {
//
}
}

···

On Fri, Dec 23, 2016 at 8:35 AM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

Hi Marco,

This idea has already been discussed on this list; however,
source-breaking changes require "extreme" justification and this particular
idea has not been found to provide obvious benefit. Moreover, Swift cases
allow fallthrough, which is less explicable when you surround each case
with braces.

The focus of this phase of Swift Evolution is listed on the GitHub site
and is generally clustered around ABI stability and completing generics.

Cheers,

Xiaodi
On Fri, Dec 23, 2016 at 07:04 Marco Scannadinari via swift-evolution < > swift-evolution@swift.org> wrote:

Hi,

I found it odd that the `label:` style is used for switch-case conditions,
considering that Swift does not have implicit fallthrough. To me the label
style only makes sense if you think of conditions essentially as labels for
a goto statement, which implies fallthrough.

Personally I think this syntax would make more sense:

switch condition {
  case 1 {
    //
  }

  case 2 {
    //
  }
}

This is how Rust implements match, although it is an expression so it
especially applies to that context. Nonetheless I think the above syntax
not only looks a lot nicer but makes more sense, especially since the
current syntax is the only instance where Python-style colons and
indentation are used for designating sections of code rather than braces.

Thoughts?

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