<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Taras,</div><div><br></div><div>I don't think the syntax { x in ... } is a hindrance for your proposal of turning all code blocks into closures, as all code blocks currently have no arguments and in that case both variants look the same. All code blocks with the exception of function bodies but I think having these looking different is ok.</div><div><br></div><div>An advantage of the current syntax is that you can leave off the parentheses when calling a closure if it is the last argument which already enables the syntax you would like for "local":</div><div><br></div><div>let x = local {</div><div> ...</div><div>}</div><div><br></div><div>This requires having the arguments inside the braces to allow for things like these:</div><div><br></div><div>someCollection.forEach { x in ... }</div><div>File.open("some/path") { file in ... } // having the file closed automatically</div><div><br></div><div>Such usage patterns would look awkward with arguments outside of the braces and they are very common and very useful.</div><div><br></div><div>Actually I was very surprised to see that your example with "local" returning a tuple did not work. The type inferencer should be able to infer the result type T to be a tuple without problems.</div><div><br></div><div>-Thorsten </div><div><br></div><div>Am 13.12.2015 um 05:14 schrieb Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Dear all, <br class=""><br class="">first of all, thank you for giving the community the opportunity to influence the future of Swift. This is a strong move, which shows how passionate the Swift team is about their language and how you guys want to make it the best. <br class=""><br class="">Personally, I am a huge fan of streamlined, logically concise concepts as well as syntax in programming languages. This is an area where Swift both excels at (love what you do with types in the compiler) but also sometimes lacking, as there seems to be a lot of idiosyncrasy, as evident from the huge number of language keywords and compiler attributes. Here, I would like to discuss some of the idiosyncrasy with closures. As I am trying to throw some random ideas out there, my post might be a bit chaotic, so please bear with me. Besides, I literally started playing around with Swift only few hours ago (I know, I know, I’m late), so my practical knowledge of the language is very limited. <br class=""><br class="">1. I always wondered about the specific closure syntax { A -> B in … }. The type annotation is within the block for some reason and the there is the keyword ‘in’, which is usually associated with the for loop. My proposal would be to change this to simply:<br class=""><br class=""> A -> B { … }<br class=""><br class="">That is, the closure declaration closely mirrors the function declaration, but without the 'func name’ part. This is far from being just a cosmetic change though. Rather, it has some far-reaching consequences to how the concept of closure is applied to the language, but I believe that this would make Swift much more streamlined and concise (and also solve some other issues in the process). <br class=""><br class="">The crucial point is that the type annotation is (and should be) optional. Which means that every code block { … } is a closure. I think this fundamentally makes a lot of sense. So, a function declaration is just a closure associated with a name identifier (aka. injected into the namespace). Similarly, code blocks used in statements such as for and do have local lexical scope, which makes them essentially compatible closures as far as I can see. <br class=""><br class="">Essentially, this approach radically simplifies the language both from the syntax standpoint — closures and funcs are using the same syntax, the notion of code blocks is removed from the language; but also from the semantics standpoint. For instance, one can give more formal definitions for statements, which opens the path of treating statements as expressions (see <a href="https://lists.swift.org/pipermail/swift-evolution/2015-December/000133.html" class="">https://lists.swift.org/pipermail/swift-evolution/2015-December/000133.html</a>). For instance, current if is of type (Bool, ()->())->(), but it can easily be redeclared as (Bool, ()->T)->T, which opens way to nice things like <br class=""><br class=""> let x = if(…) { .. some complex setup code..; value1} else { … other code..; value2}<br class=""><br class="">Similarly, do can be used to incapsulate auxiliary computations in the local scope (see below).<br class=""><br class="">2. Another closure limitation is that return type inference does not work with longer closures (but they should). Here a particular use case. Due to my work, I program a lot with R (which is sometimes a neat language in its own right). A particular paradigm I find very useful is to use anonymous code blocks in local scope to prevent namespace pollution, e.g. (in R code)<br class=""><br class=""> dataset <- local({<br class=""> a <- some_computation<br class=""> b <- some_computation<br class=""><br class=""> a combined with b<br class="">})<br class=""><br class="">// a and b are not visible in the outer scope anymore<br class=""><br class="">In JavaScript, people often use anonymous functions for the same effect. The nice thing about this paradigm is that it allows one to properly isolate data dependency from each other, give the compiler a better sense of variable lifespan and overall make your code much nicer to read. Of course, in Swift this can be done with nested functions or closures, but its the question of aesthetics. At any rate, the R function is very easy to emulate in Swift:<br class=""><br class=""> func local<T>(closure: () -> T) -> T {<br class=""> return closure()<br class=""> }<br class=""><br class="">which works beautifully, e.g.<br class=""><br class=""> let (a1,a2) = local({return(1, 2)}<br class=""><br class="">However, if I want to use more complex code, I need to explicitly declare the closure type:<br class=""><br class=""> let (a1, a2) = local({ () -> (Int, Int) in<br class=""> let x2 = x*2<br class=""><br class=""> return (x2, x2+1)<br class=""> })<br class=""><br class=""><br class="">This is bulky, and frankly, unnecessary, as the compiler can easily infer the return type of the closure. <br class=""><br class="">BTW, combined with proposal in 1., this style of programming just becomes the beautiful<br class=""><br class="">let (a1, a2) = do {<br class=""> .. do something ..<br class=""> return(…, …) // or simply (…, …)<br class="">}<br class=""><br class=""><br class="">Summary TL;DR version of the proposal: <br class=""><br class="">replace the {A->B in …} closure syntax by A->B {…} — where type declaration is optional, remove the concept of code block (replace it by closure) and statements that take blocks/closures typed expressions. Improve type inference for return values. Current syntactic sugar for closures such as anonymous arguments and last line as return values should be preserved. <br class=""><br class="">Advantages: streamlines the language, solves a number of issues at the same time (idiosyncrasy, operators as expressions). In the end, makes the language easier to use and also to understand conceptually. <br class=""><br class="">Disadvantages: I honestly can’t see a single one<br class=""><br class="">Implementation challenge: would requires a parser change that might be non-trivial. I can also imagine that a lot of refactoring in the compiler code is necessary in regards to how statements work — but this might pay off as in the end, the compiler only needs to deal with closures and calls, which simplifies optimisation. And Swift is already great at aggressive inlining of closures. <br class=""><br class="">Impact on existing code: the syntax of closure declarations can be automatically ported as the rewrite rule is trivial. As far as I can see, changing code blocks to closures won’t have any impact on the semantics of the control structures, because the blocks are already using lexical scope. <br class=""><br class="">Eager to hear your thoughts on this!<br class=""><br class="">Cheers, <br class=""><br class="">Taras
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1MXK54sosN3xru3iYcLt0oBZ2w20i49gyogXctgrspd6a6Hj7ZQ6DWm2MZfIp6hnlGxPNZECuHLcwpV8vAhmdADPgafzH4LXjUYJQ-2BcXuF39-2B-2FAxpV-2BbM3TJdjFqM5mE-2BysFi-2BOste-2BAFK9m3P7h8YV4AvO-2BFWUp8SCb72QovA8sYXr-2FpeBY9S-2B6GJ88QGSGbx-2BoYj56tzKSzK1uwmRppcoPLANoMK1LWFO-2FBa0KKzY-3D" alt="" width="1" height="1" border="0" style="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 type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>