Never mind, that would not work for returning<span></span> from a function. <br><br>On Monday, December 7, 2015, J. Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com">cheyo@masters3d.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about something like this? <br><div><br></div>let result = if bool return 1 else 2<br><br><br><br>On Monday, December 7, 2015, Cameron Knight via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Why not use a keyword? What if, the keyword 'returning' (or something like that) was used to specify the control flow behavior.</div><div><br></div><div>// Replaces ternary operator</div><div>let paint.color = returning if door.color == .Red { .Black } else { door.color }</div><div><br></div><div>// Supports additional conditions</div><div>let paint.finish = returning switch paint.color {</div><div><span style="white-space:pre-wrap"> </span>case .Black:</div><div><span style="white-space:pre-wrap"> </span>.Matte</div><div><span style="white-space:pre-wrap"> </span>case .White:</div><div><span style="white-space:pre-wrap"> </span>.Eggshell</div><div><span style="white-space:pre-wrap"> </span>default:</div><div><span style="white-space:pre-wrap"> </span>.Gloss</div><div>}</div><div><br></div><div>// Removes ambiguity of single statement behavior</div><div>let ages: [Int] = people.map returning { $0.age }</div><div><br></div><div>// Perhaps overreaching a bit</div><div>let label = returning UILabel(frame: CGRect.zero) {</div><div><span style="white-space:pre-wrap"> </span>.text = "Hello World"</div><div><span style="white-space:pre-wrap"> </span>.color = UIColor.red</div><div>}</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div>On Dec 6, 2015, at 4:56 PM, Chris Lattner via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Dec 6, 2015, at 12:17 PM, Per Melin <<a>p@greendale.se</a>> wrote:</div><br><div><div dir="ltr">On Sat, Dec 5, 2015 at 7:15 PM, Chris Lattner <span dir="ltr"><<a>clattner@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not even Slava Pestov would factor Swift that aggressively.</div></div></div></div></blockquote><br></div><div>Underestimating Slava is not a good idea! :-)</div><div><br></div><div>-Chris</div></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eABgjBqknOdLnwNfyLqbw6U-2BZOY4o2z70lPUq2Lz8gPaV-2BtZo3snpIUa63YT-2FUZ7qwktBbgDiqrJx0-2BuHU6WZH9qLPArfMNX8VuIaDxP5G2VNvIx-2F4oVZotJ-2BAguHQH-2FI6GVGOfMdWRhKTJwJmwmHY-2Bu4unCgotSeZ56Jc8-2B3ICLjGN7rp6fnQeR55fv8SFzDMGwxX3QyCd7aiVLkPdBgdcNbELXZte64dAcsSXrf-2BY-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OWK4tSasaK2n-2FQIIcS9Ug-2FuFXG-2BJ3z6cFMLgm306hDcBtnKodRcjTkx57EAnAPddLS9FMUNIBP5iqW-2Bg0owRnkbtaPSKOMhX4sVWFBlJAf0xB9zdDTjRAoYJ8-2BG-2FDEW4Noa8AVBTPyPCNgZKwREJBscd2Jp84OwXv42sBjTc4-2FMYImrg-2BkwBAhklu4MIo3OANyruyX-2Bo-2Bb6Z5VEhn7VaYTqJ53WxX4bz7Ar-2BHjcxMDU-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
</blockquote>
</blockquote>