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