Control Flow Expressions

Sergey_Shulepov · December 4, 2015, 11:05am

Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!

masters3d · December 4, 2015, 12:14pm

I like it. Related.

https://lists.swift.org/pipermail/swift-evolution/2015-December/000098.html

The switch would be interesting if it could be done in one line.

···

On Friday, December 4, 2015, Sergey Shulepov <s.pepyakin@gmail.com> wrote:

Hello.

It would be cool if control flow statements like "switch", "if" can be
used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it
feasible to introduce such change at the moment, but at least, I would like
to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

ChanMaxthon · December 4, 2015, 11:07am

I believe switch-as-an-expression can be implemented as a dictionary lookup, and if-as-an-expression is the ternary operator ?:

···

On Dec 4, 2015, at 19:05, Sergey Shulepov <s.pepyakin@gmail.com> wrote:

Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

masters3d · December 5, 2015, 3:02pm

Hi Sergey,

Are you thinking on writing the formal proposal for the if expression?

https://lists.swift.org/pipermail/swift-evolution/2015-December/000165.html

···

On Friday, December 4, 2015, Sergey Shulepov <s.pepyakin@gmail.com> wrote:

Hello.

It would be cool if control flow statements like "switch", "if" can be
used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it
feasible to introduce such change at the moment, but at least, I would like
to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · December 5, 2015, 6:15pm

FWIW, I (and many other people) would like to consider turning many statement-y things in swift into expressions. I’d love to see the weird ?: ternary operator get nuked and replaced with an if/else expression of some sort. This is an area that the apple team hasn’t had bandwidth to consider carefully.

That said, there are challenges here in the details. How will the grammar work? Exactly which statements should be included (certainly if and switch, any others)?

Further, it is important to consider whether the code written using this will actually be *better* than the code written with these things as statements. For example, the “switch” blocks tend to be very large, and turning them into expressions encourages additional indentation. Swift already allows ‘let’ values to be initialized on multiple paths, so is the win actually that great?

Given that statements-as-expressions would provide another way to do things (they are a purely syntax extension) the barrier should high to add them. They will add complexity and surface area to the language, so they need to pay that complexity.

-Chris

···

On Dec 4, 2015, at 3:05 AM, Sergey Shulepov <s.pepyakin@gmail.com> wrote:

Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.

Joe_Groff · December 4, 2015, 5:43pm

A dictionary lookup works in some cases, but is likely to be slower without optimizer heroics. Furthermore, you can't bind pattern variables or get exhaustiveness checking out of a dictionary.

-Joe

···

On Dec 4, 2015, at 3:07 AM, Maxthon Chan <xcvista@me.com> wrote:

I believe switch-as-an-expression can be implemented as a dictionary lookup, and if-as-an-expression is the ternary operator ?:

Sergey_Shulepov · December 4, 2015, 11:39am

Agree on the if-as-an-expression part, that is possible, but it can be cumbersome if branches contain more than few trivial expressions.
Whenever such situations occur you often have to break your expressions to separate methods just to split things up.

As for switch-as-an-expression, I'm not sure I got it right, can you elaborate on this?

···

On 04 Dec 2015, at 14:07, Maxthon Chan <xcvista@me.com> wrote:

I believe switch-as-an-expression can be implemented as a dictionary lookup, and if-as-an-expression is the ternary operator ?:

On Dec 4, 2015, at 19:05, Sergey Shulepov <s.pepyakin@gmail.com> wrote:

Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Jon_Hull · December 5, 2015, 3:35pm

Don’t we already have the following?

let message:String = (x % 2) ? “x is even” : “x is odd"

···

On Dec 5, 2015, at 7:02 AM, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

Hi Sergey,

Are you thinking on writing the formal proposal for the if expression?

[swift-evolution] ternary operator ?: suggestion

On Friday, December 4, 2015, Sergey Shulepov <s.pepyakin@gmail.com <mailto:s.pepyakin@gmail.com>> wrote:
Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Jon_Hull · December 5, 2015, 3:41pm

Sorry, that should be:

let message:String = (x % 2 == 0) ? “x is even” : “x is odd”

···

On Dec 5, 2015, at 7:35 AM, Jonathan Hull <jhull@gbis.com> wrote:

Don’t we already have the following?

let message:String = (x % 2) ? “x is even” : “x is odd"

On Dec 5, 2015, at 7:02 AM, J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

Hi Sergey,

Are you thinking on writing the formal proposal for the if expression?

[swift-evolution] ternary operator ?: suggestion

On Friday, December 4, 2015, Sergey Shulepov <s.pepyakin@gmail.com <mailto:s.pepyakin@gmail.com>> wrote:
Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
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
https://lists.swift.org/mailman/listinfo/swift-evolution

hartbit · December 5, 2015, 3:56pm

The ternary operator is indeed equivalent to an if expression but:

1) There is no equivalent for switch.
2) There is also a proposition to remove the ternary operator in favour of a if expression.

David.

···

On 05 Dec 2015, at 16:41, Jonathan Hull <jhull@gbis.com> wrote:

Sorry, that should be:

let message:String = (x % 2 == 0) ? “x is even” : “x is odd”

On Dec 5, 2015, at 7:35 AM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

Don’t we already have the following?

let message:String = (x % 2) ? “x is even” : “x is odd"

On Dec 5, 2015, at 7:02 AM, J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

Hi Sergey,

Are you thinking on writing the formal proposal for the if expression?

[swift-evolution] ternary operator ?: suggestion

On Friday, December 4, 2015, Sergey Shulepov <s.pepyakin@gmail.com <mailto:s.pepyakin@gmail.com>> wrote:
Hello.

It would be cool if control flow statements like "switch", "if" can be used as expressions, such as in languages like Scala, Rust and Kotlin,
so instead of writing:

var message: String
if x % 2 == 0 {
message = "x is even"
} else {
message = "x is odd"
}

you can write:

let message: String = if x % 2 == 0 { "x is even" } else { "x is odd" }

I'm not into any kind of compiler development, and don't know is it feasible to introduce such change at the moment, but at least, I would like to hear why not.
Thanks!
_______________________________________________
swift-evolution mailing list
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

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

Per_Melin · December 6, 2015, 8:17pm

If you give functions implicit return at the same time – as in Haskell,
Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no
need for additional indentation half of the time.

I really, really like it in many of the mentioned languages, but I expect
that the C crowd will vehemently disagree. And maybe Swift is sufficiently
different from those languages that it makes less sense here. For example,
regardless of project, my average function body size in Erlang hovers
around two lines. Not even Slava Pestov would factor Swift that
aggressively.

···

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com> wrote:

Further, it is important to consider whether the code written using this
will actually be *better* than the code written with these things as
statements. For example, the “switch” blocks tend to be very large, and
turning them into expressions encourages additional indentation.

Chris_Lattner · December 6, 2015, 10:56pm

Further, it is important to consider whether the code written using this will actually be *better* than the code written with these things as statements. For example, the “switch” blocks tend to be very large, and turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell, Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it is *feature* of swift that statements an declarations start with keywords. This greatly simplifies the grammar in various ways, and allows declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return foo()" for example, you don’t want to take “tail” as a keyword to make “tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

···

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se> wrote:
On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

Cameron_Knight · December 7, 2015, 7:24pm

Why not use a keyword? What if, the keyword 'returning' (or something like that) was used to specify the control flow behavior.

// Replaces ternary operator
let paint.color = returning if door.color == .Red { .Black } else { door.color }

// Supports additional conditions
let paint.finish = returning switch paint.color {
  case .Black:
    .Matte
  case .White:
    .Eggshell
  default:
    .Gloss
}

// Removes ambiguity of single statement behavior
let ages: [Int] = people.map returning { $0.age }

// Perhaps overreaching a bit
let label = returning UILabel(frame: CGRect.zero) {
.text = "Hello World"
.color = UIColor.red
}

I think it adds clarity without too much syntax bloat. I haven't thought out all the corner cases though, so maybe I'm missing something obvious.

···

On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se <mailto:p@greendale.se>> wrote:

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
Further, it is important to consider whether the code written using this will actually be *better* than the code written with these things as statements. For example, the “switch” blocks tend to be very large, and turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell, Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it is *feature* of swift that statements an declarations start with keywords. This greatly simplifies the grammar in various ways, and allows declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return foo()" for example, you don’t want to take “tail” as a keyword to make “tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

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

masters3d · December 7, 2015, 9:33pm

How about something like this?

let result = if bool return 1 else 2

···

On Monday, December 7, 2015, Cameron Knight via swift-evolution < swift-evolution@swift.org> wrote:

Why not use a keyword? What if, the keyword 'returning' (or something like
that) was used to specify the control flow behavior.

// Replaces ternary operator
let paint.color = returning if door.color == .Red { .Black } else {
door.color }

// Supports additional conditions
let paint.finish = returning switch paint.color {
case .Black:
.Matte
case .White:
.Eggshell
default:
.Gloss
}

// Removes ambiguity of single statement behavior
let ages: [Int] = people.map returning { $0.age }

// Perhaps overreaching a bit
let label = returning UILabel(frame: CGRect.zero) {
.text = "Hello World"
.color = UIColor.red
}

I think it adds clarity without too much syntax bloat. I haven't thought
out all the corner cases though, so maybe I'm missing something obvious.

On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se > <javascript:_e(%7B%7D,'cvml','p@greendale.se');>> wrote:

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com > <javascript:_e(%7B%7D,'cvml','clattner@apple.com');>> wrote:

Further, it is important to consider whether the code written using this
will actually be *better* than the code written with these things as
statements. For example, the “switch” blocks tend to be very large, and
turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell,
Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no
need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it
is *feature* of swift that statements an declarations start with keywords.
This greatly simplifies the grammar in various ways, and allows
declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return
foo()" for example, you don’t want to take “tail” as a keyword to make
“tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

_______________________________________________
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

riley · December 7, 2015, 9:43pm

So instead of chaining convenience initializers to required ones via self.init(), you’d recommend instead assigning them directly to self? I think this would be a nice change; currently it can be hard to know the correct method of chaining initializers (at least as far as I’ve seen when attempting to explain it to newcomers).

Proposed new rules for initialization:

required initializers: must call super (unless base class)
convenience initializers: must assign to self via a required initializer

I think this also would help with the confusion of why convenience methods can’t call super, but required ones can, since now convenience methods can’t chain to any initializers directly. Thoughts from others?

···

On Dec 7, 2015, at 1:33 PM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

How about something like this?

let result = if bool return 1 else 2

On Monday, December 7, 2015, Cameron Knight via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Why not use a keyword? What if, the keyword 'returning' (or something like that) was used to specify the control flow behavior.

// Replaces ternary operator
let paint.color = returning if door.color == .Red { .Black } else { door.color }

// Supports additional conditions
let paint.finish = returning switch paint.color {
  case .Black:
    .Matte
  case .White:
    .Eggshell
  default:
    .Gloss
}

// Removes ambiguity of single statement behavior
let ages: [Int] = people.map returning { $0.age }

// Perhaps overreaching a bit
let label = returning UILabel(frame: CGRect.zero) {
  .text = "Hello World"
  .color = UIColor.red
}

I think it adds clarity without too much syntax bloat. I haven't thought out all the corner cases though, so maybe I'm missing something obvious.

On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se <>> wrote:

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com <>> wrote:
Further, it is important to consider whether the code written using this will actually be *better* than the code written with these things as statements. For example, the “switch” blocks tend to be very large, and turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell, Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it is *feature* of swift that statements an declarations start with keywords. This greatly simplifies the grammar in various ways, and allows declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return foo()" for example, you don’t want to take “tail” as a keyword to make “tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

_______________________________________________
swift-evolution mailing list
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

riley · December 7, 2015, 9:44pm

Sorry y’all, wrong thread. Ignore this past email.

···

On Dec 7, 2015, at 1:43 PM, Riley Testut <rileytestut@gmail.com> wrote:

So instead of chaining convenience initializers to required ones via self.init(), you’d recommend instead assigning them directly to self? I think this would be a nice change; currently it can be hard to know the correct method of chaining initializers (at least as far as I’ve seen when attempting to explain it to newcomers).

Proposed new rules for initialization:

required initializers: must call super (unless base class)
convenience initializers: must assign to self via a required initializer

I think this also would help with the confusion of why convenience methods can’t call super, but required ones can, since now convenience methods can’t chain to any initializers directly. Thoughts from others?

On Dec 7, 2015, at 1:33 PM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

How about something like this?

let result = if bool return 1 else 2

On Monday, December 7, 2015, Cameron Knight via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Why not use a keyword? What if, the keyword 'returning' (or something like that) was used to specify the control flow behavior.

// Replaces ternary operator
let paint.color = returning if door.color == .Red { .Black } else { door.color }

// Supports additional conditions
let paint.finish = returning switch paint.color {
  case .Black:
    .Matte
  case .White:
    .Eggshell
  default:
    .Gloss
}

// Removes ambiguity of single statement behavior
let ages: [Int] = people.map returning { $0.age }

// Perhaps overreaching a bit
let label = returning UILabel(frame: CGRect.zero) {
  .text = "Hello World"
  .color = UIColor.red
}

I think it adds clarity without too much syntax bloat. I haven't thought out all the corner cases though, so maybe I'm missing something obvious.

On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se <>> wrote:

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com <>> wrote:
Further, it is important to consider whether the code written using this will actually be *better* than the code written with these things as statements. For example, the “switch” blocks tend to be very large, and turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell, Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it is *feature* of swift that statements an declarations start with keywords. This greatly simplifies the grammar in various ways, and allows declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return foo()" for example, you don’t want to take “tail” as a keyword to make “tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

_______________________________________________
swift-evolution mailing list
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

masters3d · December 7, 2015, 9:42pm

Never mind, that would not work for returning from a function.

···

On Monday, December 7, 2015, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

How about something like this?

let result = if bool return 1 else 2

On Monday, December 7, 2015, Cameron Knight via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Why not use a keyword? What if, the keyword 'returning' (or something
like that) was used to specify the control flow behavior.

// Replaces ternary operator
let paint.color = returning if door.color == .Red { .Black } else {
door.color }

// Supports additional conditions
let paint.finish = returning switch paint.color {
case .Black:
.Matte
case .White:
.Eggshell
default:
.Gloss
}

// Removes ambiguity of single statement behavior
let ages: [Int] = people.map returning { $0.age }

// Perhaps overreaching a bit
let label = returning UILabel(frame: CGRect.zero) {
.text = "Hello World"
.color = UIColor.red
}

I think it adds clarity without too much syntax bloat. I haven't thought
out all the corner cases though, so maybe I'm missing something obvious.

On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:

On Dec 6, 2015, at 12:17 PM, Per Melin <p@greendale.se> wrote:

On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner@apple.com> wrote:

Further, it is important to consider whether the code written using this
will actually be *better* than the code written with these things as
statements. For example, the “switch” blocks tend to be very large, and
turning them into expressions encourages additional indentation.

If you give functions implicit return at the same time – as in Haskell,
Erlang, Scala, Rust, Ruby, Lisp/Scheme/Clojure, etc – there would be no
need for additional indentation half of the time.

This isn’t something that I’m personally interested in. I think that it
is *feature* of swift that statements an declarations start with keywords.
This greatly simplifies the grammar in various ways, and allows
declmodifiers to be introduced without taking keywords space.

For example, relevant to this proposal, if/when we support “tail return
foo()" for example, you don’t want to take “tail” as a keyword to make
“tail foo()” work.

Not even Slava Pestov would factor Swift that aggressively.

Underestimating Slava is not a good idea! :-)

-Chris

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