Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-06 Thread Chris Lattner via swift-evolution
> On Jan 5, 2016, at 10:57 AM, Dennis Lysenko > wrote: > > Chris, interesting tidbit. I wasn't aware of that. Is sourcekit considered to > be within the scope of the swift-evolution mailing list? No, it would be better to discuss it on swift-dev. -Chris

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-05 Thread Dennis Lysenko via swift-evolution
Everyone, The sticking point here is that xcode generates the first syntax automatically. Simply filing a radar about this would be useless, so I believe the original proposal is meant to sort-of "light a fire" under the Xcode team; by introducing a new language feature they would be forced to

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-05 Thread Chris Lattner via swift-evolution
> On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution > wrote: > > Everyone, > > The sticking point here is that xcode generates the first syntax > automatically. > > Simply filing a radar about this would be useless, so I believe the original >

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-05 Thread Kevin Ballard via swift-evolution
On Tue, Jan 5, 2016, at 10:47 AM, Chris Lattner via swift-evolution wrote: > > > On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution > > wrote: > > > > Everyone, > > > > The sticking point here is that xcode generates the first syntax > > automatically.

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread Félix Cloutier via swift-evolution
I like this syntax, but I don't like that it could be ambiguous with successively calling animateWithDuration then some function called completion. Other than that, I think that developers should be smart enough to exercise self-restraint with trailing closures when they're not appropriate. I

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread Kevin Ballard via swift-evolution
What's the point of this? What problem does it solve? If you don't want a trailing closure, just don't use trailing closure syntax. I don't see what benefit there is in explicitly annotating the function to disallow trailing closure syntax with it; just because you don't want to use trailing

[swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread QQ Mail via swift-evolution
Hi, All: trailing closure is good for most cases, but sometimes it is also make code unclear, for example: UIView.animateWithDuration(0.3, animations: { () -> Void in // animation code here }) { (Bool) -> Void in // completion code here } the label been removed

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread Vincent Esche via swift-evolution
This should not be a keyword. Neither should it be part of the language. Auto-completion (assuming you’re talking about that) is not a language feature. It’s a feature of your editor/IDE. And thus it should be a default/setting therein if at all. Similarly Xcode tends to auto-complete "() ->

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread Alex Migicovsky via swift-evolution
I think instead of an attribute I’d prefer rules that allow trailing closures at call sites. The most straightforward solution would be to only allow using trailing closures at the call site if the invoked function has a single closure that’s the last parameter. I think the only unfortunate

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

2016-01-04 Thread Michel Fortin via swift-evolution
Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution a écrit : > I would like to write like this: > > UIView.animateWithDuration(0.3, > > animations: { () -> Void in > // animation code here > }, > completion: { Bool -> Void in > //