> 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
__
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.
> >
> > Simply filing a r
Chris, interesting tidbit. I wasn't aware of that. Is sourcekit considered
to be within the scope of the swift-evolution mailing list?
On Tue, Jan 5, 2016 at 1:47 PM Chris Lattner wrote:
>
> > On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution <
> swift-evolution@swift.org> 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.
>
> Simply filing a radar about this would be useless, so I believe the original
> proposal is meant to sort-of "li
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 su
Hi everybody,
I do agree with Kevin : trailing closures is only a possibility offered by the
language, you are not forced to use it.
In the case you show, I agree that the second syntax is more readable than the
first one. Good news is : it does compile :-).
I think adding a specific keyword or
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 closur
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 do
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
> // completion code here
> }
>
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 aspe
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 "() -> ()”-
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
12 matches
Mail list logo
