[swift-evolution] Control Flow Expressions

[Riley Testut]

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

> On Dec 7, 2015, at 1:43 PM, Riley Testut <rileytestut at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <>> wrote:
>>> 
>>> 
>>>> On Dec 6, 2015, at 12:17 PM, Per Melin <p at greendale.se <>> wrote:
>>>> 
>>>> On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <clattner at 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 at swift.org <>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/bf9b1590/attachment.html>