Don’t get me wrong, I’m not a huge fan of having extra punctuation around, but
as a matter of syntactic consistency, it seems the right thing to do. It’s
adding a single character (less than the `do` alternative that some are
suggesting.
It seems like the arguments against it are the same as the arguments for
eliminating curly braces entirely— they’re ugly. However it’s been decided
that we’re going to use curly braces everywhere but here.
As an instructor, I’m not sure how I would explain to a student why everywhere
else there is the potential for more than one statement in a syntactic slot
they should use curly braces but that `case` is the sole exception because
somebody did it that way in the 70’s. We’ve already decided to throw away
legacy C syntax in `for` loops, why not here while we have a shot at
consistency?
Is there anywhere else that a sequence of statements isn't wrapped?
for <#item#> in <#items#> {
<#code#>
}
if <#condition#> {
<#code#>
} else if <#condition#> {
<#code#>
} else {
<#code#>
}
while <#condition#> {
<#code#>
}
repeat {
<#code#>
} while <#condition#>
var x:Type {
get {
return _x
}
set {
_x=newValue
}
}
> On Jul 7, 2016, at 13:47 , Brandon Knope <[email protected]> wrote:
>
> But in general, if I use enums, I have more cases than I normally would have
> of if-else statements.
>
> I try not to have many if-else chains but I generally have 2+ cases which
> would result in more braces than my typical if-else
>
>> On Jul 7, 2016, at 4:41 PM, G B via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> The same can be said for if/else constructs though— all those braces get
>> heavy if they’re all wrapping one line each. Python does away with the
>> braces and relies on indentation, but Swift has explicitly stated that it
>> will not follow that path— yet case statements seem an exception. It’s a
>> collection of statements, they should be grouped in braces.
>>
>> Your example is still only one line per case, but those braces are less of a
>> problem when amortized over more lines (note that there are extra braces
>> enforced by the `if` and `else`):
>>
>> switch x {
>> case 0 {
>> //a comment or two describing what's happening in this particular case
>> //because commenting is good practice
>> result=runSomeCode()
>> if result {
>> //do something here
>> }
>> else {
>> //maybe some more stuff
>> print(0)
>> }
>> }
>>
>> case 1 {
>> //a comment or two describing what's happening in this particular case
>> //because commenting is good practice
>> result=runSomeCode()
>> if result {
>> //do something here
>> }
>> else {
>> //maybe some more stuff
>> print(1)
>> }
>> }
>>
>> case 2 {
>> //a comment or two describing what's happening in this particular case
>> //because commenting is good practice
>> result=runSomeCode()
>> if result {
>> //do something here
>> }
>> else {
>> //maybe some more stuff
>> print(2)
>> }
>> }
>>
>> default {
>> //a comment or two describing what's happening in this particular case
>> //because commenting is good practice
>> result=runSomeCode()
>> if result {
>> //do something here
>> }
>> else {
>> //maybe some more stuff
>> print(0)
>> }
>> }
>> }
>>
>>
>>
>>> On Jul 7, 2016, at 13:24 , Brandon Knope <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> When each case only takes up one line, it may look nice and concise. But
>>> what happens in the common case when your case takes up more lines and you
>>> indent your braces?
>>>
>>>> switch x {
>>>> case 0 { print(0) }
>>>> case 1 { print(1) }
>>>> case 2 { print(2) }
>>>> default { print("other”) }
>>>> }
>>>
>>> switch x {
>>> case 0 {
>>> print(0)
>>> }
>>> case 1 {
>>> print(1)
>>> }
>>> case 2 {
>>> print(2)
>>> }
>>> default {
>>> print("other”)
>>> }
>>> }
>>>
>>> I think this looks much heavier and harder to read. All the braces detract
>>> from the important stuff
>>>
>>> Brandon
>>>
>>>
>>>
>>>>
>>>> The colon syntax evokes a label, but the modern, complex `case` statements
>>>> in Swift don’t act much like labels.
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
