[swift-evolution] Code blocks and trailing closures

[Rien]

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() }

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.
> 
> 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