Re: [swift-evolution] Extending trailing closure sugar similar to property accessors
That makes sense. I thought there may be a parsing trick involved with the way property accessors are designed. > On Nov 2, 2017, at 9:00 PM, Slava Pestov wrote: > > This is not possible in general, since we want the parser to be able to parse > code without having knowledge of declarations and their types (which might > come from other modules). Overloaded declarations complicate this further. > > I agree that the existing property syntax already has this issue, which is > unfortunate, but we should not introduce features that make the problem worse. > > Slava ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Extending trailing closure sugar similar to property accessors
> On Nov 2, 2017, at 5:58 PM, Eric Summers wrote: > > A similar problem exists with property accessors. Although you could call > those keywords, they will probably be extensible when behaviors are > introduced leading to a similar situation. It can be worked around by making > the priority of argument labels higher then function calls within the curly > brackets. This is not possible in general, since we want the parser to be able to parse code without having knowledge of declarations and their types (which might come from other modules). Overloaded declarations complicate this further. I agree that the existing property syntax already has this issue, which is unfortunate, but we should not introduce features that make the problem worse. Slava ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Extending trailing closure sugar similar to property accessors
A similar problem exists with property accessors. Although you could call
those keywords, they will probably be extensible when behaviors are introduced
leading to a similar situation. It can be worked around by making the priority
of argument labels higher then function calls within the curly brackets.
Eric
> On Nov 2, 2017, at 8:51 PM, Slava Pestov via swift-evolution
> wrote:
>
>
>
>> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> // A sugar similar to property accessors for multiple trailing closures:
>> foobar(a: 1, b: 2) {
>> completionBlock { x, y in
>> // ...
>> }
>> failureBlock { i, j in
>> // ...
>> }
>> }
>
> This syntax is ambiguous. Are you passing in two trailing closures to
> foobar(), or a single trailing closure, inside which you call two top-level
> functions, completionBlock and failureBlock?
>
> Slava
>
> ___
> 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
Re: [swift-evolution] Extending trailing closure sugar similar to property accessors
> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution
> wrote:
>
> // A sugar similar to property accessors for multiple trailing closures:
> foobar(a: 1, b: 2) {
> completionBlock { x, y in
> // ...
> }
> failureBlock { i, j in
> // ...
> }
> }
This syntax is ambiguous. Are you passing in two trailing closures to foobar(),
or a single trailing closure, inside which you call two top-level functions,
completionBlock and failureBlock?
Slava
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] Extending trailing closure sugar similar to property accessors
I’d like to hear thoughts on extending trailing closure syntax to avoid long
inline closures. A significant benefit to adopting this sugar would be to
clarify indentation style for long inline closures. I apologize if this has
been brought up before, but I couldn’t find anything searching the list.
There is a lot of discussion about hacking around the issues with inline
closures. Here are a few examples:
https://www.natashatherobot.com/swift-trailing-closure-syntax/
https://owensd.io/2015/02/20/handling-multiple-closure-parameters/
https://bugs.swift.org/browse/SR-1199
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html
I think a syntax similar to property accessors to allow multiple trailing
closures could make these scenarios feel swifty. Property accessors already
have a "get" specialization that is similar to the current trailing closures
syntax, so in theory this could be a backwards compatible extension.
func foobar(a: Int, b: Int, completionBlock: ((Int, Int) -> Void),
failureBlock: ((Int, Int) -> Void) {
// ...
}
// Current syntax:
foobar(a: 1, b: 2,
completionBlock: { x, y in
// ...
},
failureBlock: { i, j in
// ...
})
// A sugar similar to property accessors for multiple trailing closures:
foobar(a: 1, b: 2) {
completionBlock { x, y in
// ...
}
failureBlock { i, j in
// ...
}
}
Best,
Eric
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
