[swift-evolution] Code blocks and trailing closures

[Rick Mann]

> On Mar 20, 2017, at 07:24 , Rien <Rien at balancingrock.nl> wrote:
> 
> Another solution to the original problem would be to allow the parameter name of the closure outside the functions parenthesis:
> 
> func test(a: Int, onError: ()->Void) {…}
> 
> could be called like this:
> 
> test(5) onError: { myErrorHandler() }

I don't think it improves the situation to do this. All this saves is a trailing closing parenthesis and a comma, and it doesn't seem any better than:

test(5, onError: { myErrorHandler() })

or

test(5,
     onError:
     {
         myErrorHandler()
     })

> 
> Myself, I would like this. It makes clear what the closure is used for, and it potentially opens up the possibility to use multiple “parameter named closures” after the function call.
> 
> It also makes it clear that this is a closure and not a code block belonging to a statement.
> 
> I guess this must have been debated already… if so, why was it rejected?
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 20 Mar 2017, at 13:13, David Rönnqvist via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Xcode can already draw boxes for nesting scopes, but it’s disabled by default. You’ll find it under: Editor > Code Folding > Focus Follows Selection.

I tend to agree features should not rely on editors. However, it seems that editor functionality does influence language and API design a lot. I don't have a specific example, but it's a feeling I've been getting lately.

In any case, that Xcode feature (focus follows selection) is interesting, but not really what I'm after. I don't want to see all scopes, I just want to see blocks called out, and I don't want to have to click to find them.


>> 
>> That said, IIRC it’s been mentioned on this list that (I’m paraphrasing) we should try and avoid designs that rely on editor functionality, and also that a Xcode is independent from the mailing list.
>> 
>> 
>>> On 20 Mar 2017, at 07:22, Rick Mann via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I actually don't like this situation, either. I find it gets a bit confusing to know what's a block and what's just nested scope. I, too, have had an impulse to have a different keyword for returning from a block, but what I really want is for the entire scope of the block to be called out differently.
>>> 
>>> This is true regardless of whether or not it's a trailing closure.
>>> 
>>> I wonder if the source editor (e.g. Xcode) could draw three sides of a box with arrows:
>>> 
>>>  {                         <--------------------+
>>>      some code                                  |
>>>      more code                                  |
>>>  }                         <--------------------+
>>> 
>>> I don't know if this would quickly get messy and distracting. It would be challenging to find exactly the right way to draw it that pleases everyone (it should, obviously, be hyper-customizable, but Apple hates settings), and to draw it to make it easy to see what it's pointing to without trampling over end-of-line comments.
>>> 
>>> Maybe subtle highlighting of the background (all the way across the window) to show block, but that makes it harder to show nested blocks.
>>> 
>>> 
>>>> On Mar 19, 2017, at 20:33 , Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I have proposed that a different keyword be used to return out of blocks. In Objective-C, I have a #define that aliases “blockreturn” and I use that exclusively in breaking out of blocks.
>>>> 
>>>> -Kenny
>>>> 
>>>> 
>>>>> On Mar 15, 2017, at 3:35 AM, Rien via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> What does the following code fragment do?
>>>>> 
>>>>> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return }
>>>>> 
>>>>> The only possible answer is: I don’t know.
>>>>> 
>>>>> The problem is finding out what the “return” statement will do.
>>>>> 
>>>>> Without knowing if the {...} is a code block or a trailing closure it is impossible to know what the return statement will do. It will either end the closure or it will end the function that contains this code block.
>>>>> 
>>>>> This could be disambiguated by using the same syntax as for lazy variables:
>>>>> 
>>>>> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message: message); return }()
>>>>> 
>>>>> Now it is clear that the return statement will only terminate the (trailing) closure.
>>>>> 
>>>>> A question to the educators on the list: Is this a real problem?
>>>>> 
>>>>> Personally, I dislike this situation, but I am also ambivalent towards the solution I just described.
>>>>> 
>>>>> Regards,
>>>>> Rien
>>>>> 
>>>>> Site: http://balancingrock.nl
>>>>> Blog: http://swiftrien.blogspot.com
>>>>> Github: http://github.com/Balancingrock
>>>>> Project: http://swiftfire.nl
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rmann at latencyzero.com
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 


-- 
Rick Mann
rmann at latencyzero.com