Hi Gwendal,
> Am 23.04.2016 um 12:18 schrieb Gwendal Roué via swift-evolution
> <[email protected]>:
>
> Hello Andrew,
>
> I'm rather embarrassed: the initial design of this proposal was based on a
> modifier of @noescape:
>
> func f(@noescape(once) closure: () -> ()) { … }
>
> But since the 0049 proposal has been accepted
> (https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md),
> @noescape is no longer an argument qualifier, but a type attribute.
maybe I cannot give competent advice from the language designers perspective,
but I can speak as a language user.
I think it is more intuitive to have the name of the argument first:
"ARGUMENT-NAME: NOESCAPE AUTOCLOSURE TYPE FOOBAR-QUALIFIER...,
NEXT-ARGUMENT-NAME..." and not "SOME-MODIFIERS-FIRST ARGUMENT-NAME:
SOME-MODIFIERS-LAST". I think the old behavior reminded me too much of C, where
the argument name is at some arbitrary place, surrounded by type names, parens,
and whatnot; "void foo(int __cdecl (*bar)(int foobar, void *context))" where
"bar" is the argument name, the first "int" is the return type of the "bar"
function, "int" and "void*" are the two argument types, and "__cdecl" is the
calling convention of the "bar" function.
And about @noescape(once)... Would it not work anymore? I know it's not part of
the current SE-0049 proposal, but I can't see why it couldn't be expanded to
include `once`. Or maybe it's just because I can't think of a realistic use
case for using "@noescape(once)".
> The `once` discussed here can not be part of the type: if noescape can
> understandably be part of the type, the fact that a function guarantees it
> will call a closure once is a quality of that function, not of the closure.
Yes it is a quality of the function and not of the type. But why not just leave
it at that place and just call it "argument qualifier"? Or maybe the general
layout changed? In Swift 2 it was "ARGUMENT_QUALIFIERS ARGUMENT_NAME:
TYPE_ATTRIBUTES TYPE", and in Swift 3 it is "ARGUMENT_NAME: ARGUMENT_QUALIFIERS
TYPE_ATTRIBUTES TYPE"?
> So the proposed @noescape(once) syntax is now confusing as it would mix a
> type attribute and a argument qualifier.
>
> I don't quite know how to escape this:
>
> // two @ signs
> func f(@noescape @once closure: () -> ()) { … }
>
> // Implies @noescape
> func f(@once closure: () -> ()) { … }
How about
func f(closure: @noescape(once) () -> ()) { ... }
-Michael
>
> I'd like advice from competent people before I would attempt a rewrite of the
> proposal.
>
> Gwendal Roué
>
>> Le 10 avr. 2016 à 23:26, Andrew Bennett <[email protected]> a écrit :
>>
>> Sorry I missed that scrolling back through the history, that proposal looks
>> great. It doesn't look like it has been submitted as a pull request to
>> swift-evolution yet though.
>>
>> On Sunday, 10 April 2016, Gwendal Roué <[email protected]> wrote:
>> Felix Cloutier already wrote one:
>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>
>> Do you think it needs to be rewritten?
>>
>> Gwendal Roué
>>
>>> Le 10 avr. 2016 à 14:56, Andrew Bennett <[email protected]> a écrit :
>>>
>>> Hi, not beyond this thread that I have seen. I think it's worth you
>>> summarizing this thread in a formal proposal and putting it up for
>>> discussion or submitting it as a PR :)
>>>
>>> On Sunday, 10 April 2016, Gwendal Roué <[email protected]> wrote:
>>> Hello all,
>>>
>>> I was wondering if this topic had evolved in anyway since its original
>>> introduction.
>>>
>>> @noescape(once) would still be a useful addition to the language!
>>>
>>> Gwendal Roué
>>>
>>>
>>>
>>>> Le 3 févr. 2016 à 22:21, Félix Cloutier via swift-evolution
>>>> <[email protected]> a écrit :
>>>>
>>>> I updated the proposal to address some concerns. It can be found at:
>>>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>>>
>>>> Things that changed:
>>>>
>>>> • It now says that the closure must be called on code paths where the
>>>> function throws;
>>>> • you can have multiple @noescape(once) parameters but they can't make
>>>> assumptions from one another.
>>>>
>>>> I'm not 100% convinced that forcing a call on code paths that throw is
>>>> always desirable. I've changed it because Chris's support probably means
>>>> that the feature has better chances of making it, but I'm not convinced
>>>> yet. If throwing allows me to return without calling the closure, I can
>>>> write this:
>>>>
>>>> do {
>>>> let foo: Int
>>>> try withLock(someLock, timeout: 0.5) {
>>>> foo = sharedThing.foo
>>>> }
>>>> } catch {
>>>> print("couldn't acquire lock fast enough")
>>>> }
>>>>
>>>> which would be kind of messy if instead, the closure needed a parameter to
>>>> tell whether the lock was acquired or not when it runs.
>>>>
>>>> Félix
>>>>
>>>> _______________________________________________
>>>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
