Modernize Switch/Case Statements?


(Joseph Essin) #1

As a budding iOS developer, I thought it might be nice if Swift were to
further improve on C's *switch* statement by using curly brackets to denote
a block instead of a colon. It seems like this would be more consistent
with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch *value* {
  case *expression* {
  }
}

I apologize if this message isn't in the right format--I've not used a
mailing list before.

Joseph Essin


(Ilya Belenkiy) #2

+1

···

On Wed, Jan 27, 2016 at 8:39 PM Joseph Essin via swift-evolution < swift-evolution@swift.org> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to
further improve on C's *switch* statement by using curly brackets to
denote a block instead of a colon. It seems like this would be more
consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch *value* {
  case *expression* {
  }
}

I apologize if this message isn't in the right format--I've not used a
mailing list before.

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


(Thorsten Seitz) #3

-1 as this is too much visual clutter IMO.

-Thorsten

···

Am 28.01.2016 um 02:35 schrieb Joseph Essin via swift-evolution <swift-evolution@swift.org>:

As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

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


(Rudolf Adamkovič) #4

+2 from me! One for curly braces and one for proper indentation.

R+

···

On 28 Jan 2016, at 02:35, Joseph Essin via swift-evolution <swift-evolution@swift.org> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

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


(Craig Cruden) #5

Replacing a “:” with a set of curly brackets for each case would quickly clutter up the statement and make it look really ugly IMHO.

If the problem is that the expression is being lost because the symbol “:” does not stand out…. then simple formatting tends to solve that (i.e. if it is multiple lines then “:” on one line and the code on the next.

···

On 2016-01-28, at 8:43:25, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

+1
On Wed, Jan 27, 2016 at 8:39 PM Joseph Essin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

Joseph Essin
_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #6

I’d say to make it optional, as the use of just a colon is great for compact switch statements with short cases, so I think they’re worth retaining.

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name. Currently they just result in a “trailing closure separated by multiple new-lines” warning, so they could perhaps be made available, in which event you could use them in larger case statements whenever you wished.

···

On 29 Jan 2016, at 22:45, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org> wrote:

+2 from me! One for curly braces and one for proper indentation.

R+

On 28 Jan 2016, at 02:35, Joseph Essin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

Joseph Essin
_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #7

I think improvements to switch, if, for, and ?: have been ruled out in the
list of already requested but rejected changes.

···

On Thursday, 28 January 2016, Craig Cruden via swift-evolution < swift-evolution@swift.org> wrote:

Replacing a “:” with a set of curly brackets for each case would quickly
clutter up the statement and make it look really ugly IMHO.

If the problem is that the expression is being lost because the symbol “:”
does not stand out…. then simple formatting tends to solve that (i.e. if it
is multiple lines then “:” on one line and the code on the next.

On 2016-01-28, at 8:43:25, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

+1
On Wed, Jan 27, 2016 at 8:39 PM Joseph Essin via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to
further improve on C's *switch* statement by using curly brackets to
denote a block instead of a colon. It seems like this would be more
consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch *value* {
  case *expression* {
  }
}

I apologize if this message isn't in the right format--I've not used a
mailing list before.

Joseph Essin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
  -- Howard.


#8

I’d say to make it optional, as the use of just a colon is great for compact switch statements with short cases, so I think they’re worth retaining.

+1

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name. Currently they just result in a “trailing closure separated by multiple new-lines” warning, so they could perhaps be made available, in which event you could use them in larger case statements whenever you wished.

Actually "do" can be used for variable scoping:

do {
    let x = Something()
}
let x = SomethingElse()

- Maximilian

···

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution <swift-evolution@swift.org>:

On 29 Jan 2016, at 22:45, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org> wrote:

+2 from me! One for curly braces and one for proper indentation.

R+

On 28 Jan 2016, at 02:35, Joseph Essin via swift-evolution <swift-evolution@swift.org> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

Joseph Essin
_______________________________________________
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


(Andrew Bennett) #9

I like this idea, but I don't have enough detail to +1.

It would be good to show how all current switch behaviour would work.

How would 'break' and 'fallthrough' work?

It seems 'break' is redundant now.

Would the following code's 'break' act on the switch, or on the for loop?

for i in 0...5 {
    switch i {
        case 4 { break }
        default { print(i) }
    }
}

···

On Saturday, 30 January 2016, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

I’d say to make it optional, as the use of just a colon is great for
compact switch statements with short cases, so I think they’re worth
retaining.

Actually, one thing we don’t have in Swift is the ability to just put
blocks (curly braces) wherever we like, which in some languages is a useful
tool for variable scope when you know you only need something for a short
time, but might want to re-use the name. Currently they just result in a
“trailing closure separated by multiple new-lines” warning, so they could
perhaps be made available, in which event you could use them in larger case
statements whenever you wished.

On 29 Jan 2016, at 22:45, Rudolf Adamkovič via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

+2 from me! One for curly braces and one for proper indentation.

R+

On 28 Jan 2016, at 02:35, Joseph Essin via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to
further improve on C's *switch* statement by using curly brackets to
denote a block instead of a colon. It seems like this would be more
consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch *value* {
  case *expression* {
  }
}

I apologize if this message isn't in the right format--I've not used a
mailing list before.

Joseph Essin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Thorsten Seitz) #10

You can use a "do" block for that.

do { ... }

-Thorsten

···

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution <swift-evolution@swift.org>:

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name.


(Brent Royal-Gordon) #11

I think improvements to switch, if, for, and ?: have been ruled out in the list of already requested but rejected changes.

First of all, the commonly requested changes list does not represent things that have been "ruled out". It represents things that have been repeatedly discussed without a satisfactory solution, so if you're going to propose something in those areas, you should familiarize yourself with that background and be prepared to address the issues that have been brought up before.

Secondly, what's been discussed in the past is making switch and if into expressions. This proposal has nothing to do with that.

···

--
Brent Royal-Gordon
Architechies


(Howard Lovatt) #12

@Brent,

You are correct with what you say. The issue to address is why there needs
to be a pressing change from C. EG in the past for switch changing default
to case _ has been rejected because C uses default. Needs a strong case for
case clauses :).

···

On 28 January 2016 at 16:54, Brent Royal-Gordon <brent@architechies.com> wrote:

> I think improvements to switch, if, for, and ?: have been ruled out in
the list of already requested but rejected changes.

First of all, the commonly requested changes list does not represent
things that have been "ruled out". It represents things that have been
repeatedly discussed without a satisfactory solution, so if you're going to
propose something in those areas, you should familiarize yourself with that
background and be prepared to address the issues that have been brought up
before.

Secondly, what's been discussed in the past is making switch and if into
expressions. This proposal has nothing to do with that.

--
Brent Royal-Gordon
Architechies

--
  -- Howard.


(‫אביאל גרוס‬‎) #13

I agree on the break and fallthrough points, I also think forcing curly braces would add unwanted complexity to simple switch blocks. Even worse - the way switch looks today it encourages clean and simple blocks, with short cases; adding curly braces might lead to huge switch cases which are impossible to follow…

···

On Jan 30, 2016, at 2:03 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

I like this idea, but I don't have enough detail to +1.

It would be good to show how all current switch behaviour would work.

How would 'break' and 'fallthrough' work?

It seems 'break' is redundant now.

Would the following code's 'break' act on the switch, or on the for loop?

for i in 0...5 {
    switch i {
        case 4 { break }
        default { print(i) }
    }
}

On Saturday, 30 January 2016, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’d say to make it optional, as the use of just a colon is great for compact switch statements with short cases, so I think they’re worth retaining.

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name. Currently they just result in a “trailing closure separated by multiple new-lines” warning, so they could perhaps be made available, in which event you could use them in larger case statements whenever you wished.

On 29 Jan 2016, at 22:45, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

+2 from me! One for curly braces and one for proper indentation.

R+

On 28 Jan 2016, at 02:35, Joseph Essin via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

As a budding iOS developer, I thought it might be nice if Swift were to further improve on C's switch statement by using curly brackets to denote a block instead of a colon. It seems like this would be more consistent with the language at large and make indention more intuitive.

Here's a quick example of what it might be.

switch value {
  case expression {
  }
}

I apologize if this message isn't in the right format--I've not used a mailing list before.

Joseph Essin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','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


(Craig Cruden) #14

I would argue that if you are in need of multiple blocks within a function that your function is not focused or concise. Unlike a language like Java, you can define functions within another function which greatly improves code structure as it allows you to write chunks of code that is used multiple times in a function but no-where else.

Haravikk, curious — how big are these functions that you feel the need for multiple blocks?

···

On 2016-01-30, at 21:51:18, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name. Currently they just result in a “trailing closure separated by multiple new-lines” warning, so they could perhaps be made available, in which event you could use them in larger case statements whenever you wished.

Actually "do" can be used for variable scoping:

do {
    let x = Something()
}
let x = SomethingElse()


(Erica Sadun) #15

do blocks don't let you introduce parameters for short-lived items:

// this is how I have to do things now

let _ : UILabel = {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
    return $0
}(UILabel())

// vs (this does not exist in the language)

do {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
}(UILabel())

-- E

···

On Jan 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution <swift-evolution@swift.org>:

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name.

You can use a "do" block for that.

do { ... }

-Thorsten


(Charles Constant) #16

-1

The more I think about the "switch" statement, the more I feel it ought to
rewritten from scratch to be based on operators, like the ternary. Whenever
I consider using a "switch" statement in my code, I feel a small twinge of
reluctance. For something as basic as choosing between more than two cases,
the syntax is too verbose for my liking.

Having said that, if we're not going to make the "switch" statement less
verbose (and let's face it, it's we're not) then we ought to at least take
advantage of its benefits. And one of those benefits is that almost all
programmers already know its syntax from other C-inspired languages. So I
don't think we should mess around with it.


(Radek Pietruszewski) #17

// this is how I have to do things now

let _ : UILabel = {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
    return $0
}(UILabel())

// vs (this does not exist in the language)

do {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
}(UILabel())

That’s an interesting pattern. I don’t think I’ve seen that one before.

How about:

do {
    let v = UILabel()
    view.addSubview(v)
    CenterViewInSuperview(v,
        horizontal: true, vertical: false)
    v.text = "Toggle me"
    v.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: v, mySwitch)
}

Is it too bad? I certainly like it better because you introduce `v` ($0) at the beginning of the block, not at the end.

And while one letter variable name is kinda gross in general, I don’t mind it in such context just like I don’t have a problem with $0 in simple closures. It’s a common practice in Ruby, for example, that doesn’t have $x to define “obvious” closure arguments as one letter variables, like so:

   articles = article_data.map { |a| Article.new(a) }

— Radek

···

On 31 Jan 2016, at 18:27, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name.

You can use a "do" block for that.

do { ... }

-Thorsten

do blocks don't let you introduce parameters for short-lived items:

// this is how I have to do things now

let _ : UILabel = {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
    return $0
}(UILabel())

// vs (this does not exist in the language)

do {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
}(UILabel())

-- E

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


(Thorsten Seitz) #18

Yep, that’s what I meant.

-Thorsten

···

Am 31.01.2016 um 20:02 schrieb Radosław Pietruszewski <radexpl@gmail.com>:

// this is how I have to do things now

let _ : UILabel = {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
    return $0
}(UILabel())

// vs (this does not exist in the language)

do {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
}(UILabel())

That’s an interesting pattern. I don’t think I’ve seen that one before.

How about:

do {
    let v = UILabel()
    view.addSubview(v)
    CenterViewInSuperview(v,
        horizontal: true, vertical: false)
    v.text = "Toggle me"
    v.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: v, mySwitch)
}

Is it too bad? I certainly like it better because you introduce `v` ($0) at the beginning of the block, not at the end.

And while one letter variable name is kinda gross in general, I don’t mind it in such context just like I don’t have a problem with $0 in simple closures. It’s a common practice in Ruby, for example, that doesn’t have $x to define “obvious” closure arguments as one letter variables, like so:

   articles = article_data.map { |a| Article.new(a) }

— Radek

On 31 Jan 2016, at 18:27, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Actually, one thing we don’t have in Swift is the ability to just put blocks (curly braces) wherever we like, which in some languages is a useful tool for variable scope when you know you only need something for a short time, but might want to re-use the name.

You can use a "do" block for that.

do { ... }

-Thorsten

do blocks don't let you introduce parameters for short-lived items:

// this is how I have to do things now

let _ : UILabel = {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
    return $0
}(UILabel())

// vs (this does not exist in the language)

do {
    view.addSubview($0)
    CenterViewInSuperview($0,
        horizontal: true, vertical: false)
    $0.text = "Toggle me"
    $0.font = UIFont.boldSystemFontOfSize(36)
    ConstrainViews("V:[view1]-30-[view2]",
        views: $0, mySwitch)
}(UILabel())

-- E

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


(Allen Ding) #19

I often do something similar to:

[ UILabel(), UILabel() ].forEach {
    view.addSuperview($0)
    $0.text = "foo"
}

Never used it for single items though. But very useful for building
complicated attributed strings.

···

On Mon, Feb 1, 2016 at 3:02 AM, Radosław Pietruszewski < swift-evolution@swift.org> wrote:

// this is how I have to do things now
let _ : UILabel = {
view.addSubview($0)
CenterViewInSuperview($0,
horizontal: true, vertical: false)
$0.text = "Toggle me"
$0.font = UIFont.boldSystemFontOfSize(36)
ConstrainViews("V:[view1]-30-[view2]",
views: $0, mySwitch)
return $0
}(UILabel())
// vs (this does not exist in the language)
do {
view.addSubview($0)
CenterViewInSuperview($0,
horizontal: true, vertical: false)
$0.text = "Toggle me"
$0.font = UIFont.boldSystemFontOfSize(36)
ConstrainViews("V:[view1]-30-[view2]",
views: $0, mySwitch)
}(UILabel())

That’s an interesting pattern. I don’t think I’ve seen that one before.

How about:

do {
let v = UILabel()
view.addSubview(v)
CenterViewInSuperview(v,
horizontal: true, vertical: false)
v.text = "Toggle me"
v.font = UIFont.boldSystemFontOfSize(36)
ConstrainViews("V:[view1]-30-[view2]",
views: v, mySwitch)
}

Is it too bad? I certainly like it better because you introduce `v` ($0)
at the beginning of the block, not at the end.

And while one letter variable name is kinda gross in general, I don’t mind
it in such context just like I don’t have a problem with $0 in simple
closures. It’s a common practice in Ruby, for example, that doesn’t have $x
to define “obvious” closure arguments as one letter variables, like so:

   articles = article_data.map { |a| Article.new(a) }

— Radek

On 31 Jan 2016, at 18:27, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution < > swift-evolution@swift.org> wrote:

Am 30.01.2016 um 10:39 schrieb Haravikk via swift-evolution < > swift-evolution@swift.org>:

Actually, one thing we don’t have in Swift is the ability to just put
blocks (curly braces) wherever we like, which in some languages is a useful
tool for variable scope when you know you only need something for a short
time, but might want to re-use the name.

You can use a "do" block for that.

do { ... }

-Thorsten

do blocks don't let you introduce parameters for short-lived items:

// this is how I have to do things now
let _ : UILabel = {
view.addSubview($0)
CenterViewInSuperview($0,
horizontal: true, vertical: false)
$0.text = "Toggle me"
$0.font = UIFont.boldSystemFontOfSize(36)
ConstrainViews("V:[view1]-30-[view2]",
views: $0, mySwitch)
return $0
}(UILabel())
// vs (this does not exist in the language)
do {
view.addSubview($0)
CenterViewInSuperview($0,
horizontal: true, vertical: false)
$0.text = "Toggle me"
$0.font = UIFont.boldSystemFontOfSize(36)
ConstrainViews("V:[view1]-30-[view2]",
views: $0, mySwitch)
}(UILabel())

-- E

_______________________________________________
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