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@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Rick Mann
rm...@latencyzero.com
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
