> On Mar 20, 2017, at 07:24 , Rien <[email protected]> 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
>> <[email protected]> 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
>>> <[email protected]> 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
>>>> <[email protected]> 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
>>>>> <[email protected]> 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
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> --
>>> Rick Mann
>>> [email protected]
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
Rick Mann
[email protected]
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
