[Proposal]: support disable to trailing closure syntax

Chenyungui · January 4, 2016, 12:45pm

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 and the code also not aligned well.
I would like to write like this:

UIView.animateWithDuration(0.3,

    animations: { () -> Void in
        // animation code here
    },
    completion: { Bool -> Void in
        // completion code here
    }
)

It is possible, just every time you have to write it manually. It’s a little wast.
So I have a thought, since we already know this function is not well suit for trailing
closure, can we add a attribute to disable it, for example:

extension UIView {

    @disable_trailing_closure
    public static func animateWithDuration(duration:NSTimeInterval, animations:()->Void, completion:()->Void) {
        // implementations ...
    }
}

I also found another one have issue for this too. link: http://www.natashatherobot.com/swift-trailing-closure-syntax/
what do you think?

Best Regards

ChenYungui

migi · January 4, 2016, 5:26pm

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 aspect of that is it’s an implicit rule which makes it harder for new devs to learn (and experienced devs to remember!).

- Alex

···

On Jan 4, 2016, at 4:45 AM, QQ Mail via swift-evolution <swift-evolution@swift.org> wrote:

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 and the code also not aligned well.
I would like to write like this:

UIView.animateWithDuration(0.3,

    animations: { () -> Void in
        // animation code here
    },
    completion: { Bool -> Void in
        // completion code here
    }
)

It is possible, just every time you have to write it manually. It’s a little wast.
So I have a thought, since we already know this function is not well suit for trailing
closure, can we add a attribute to disable it, for example:

extension UIView {

    @disable_trailing_closure
    public static func animateWithDuration(duration:NSTimeInterval, animations:()->Void, completion:()->Void) {
        // implementations ...
    }
}

I also found another one have issue for this too. link: http://www.natashatherobot.com/swift-trailing-closure-syntax/
what do you think?

Best Regards

ChenYungui

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Lily_Ballard · January 4, 2016, 6:52pm

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 closure syntax doesn't mean nobody should be able to use it.
And other people using it shouldn't affect you.

-Kevin Ballard

···

On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:

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 and the code also not aligned well. I would
like to write like this:

UIView.animateWithDuration(0.3,

animations: { () -> Void in // animation code here },
completion: { Bool -> Void in // completion code here } )

It is possible, just every time you have to write it manually. It’s a
little wast. So I have a thought, since we already know this function
is not well suit for trailing closure, can we add a attribute to
disable it, for example:

extensionUIView {

@disable_trailing_closure public static func
animateWithDuration(duration:NSTimeInterval, animations:()->Void, completion:()-
>Void) { // implementations ... } }

I also found another one have issue for this too. link:
http://www.natashatherobot.com/swift-trailing-closure-syntax/ what do
you think?

Best Regards

ChenYungui

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

michelf · January 4, 2016, 5:50pm

Maybe, instead of disallowing trailing closures, we could allow consecutive closures to be expressed like that:

UIView.animateWithDuration(0.3) {
// animation code here
} completion { success in
// completion code here
}

···

Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution <swift-evolution@swift.org> 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
    }
)

--
Michel Fortin
https://michelf.ca

Felix_Cloutier1 · January 4, 2016, 6:49pm

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 don't understand what you (QQ Mail) mean with "you have to write it manually".

Félix

···

Le 4 janv. 2016 à 12:50:15, Michel Fortin via swift-evolution <swift-evolution@swift.org> a écrit :

Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution <swift-evolution@swift.org> 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
   }
)

Maybe, instead of disallowing trailing closures, we could allow consecutive closures to be expressed like that:

UIView.animateWithDuration(0.3) {
  // animation code here
} completion { success in
  // completion code here
}

--
Michel Fortin
https://michelf.ca

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Vincent_Esche · January 4, 2016, 2:43pm

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 "() -> ()”-closures as { () -> Void in … }.
The “() -> Void in” not necessary in 99/100 cases. Still it shouldn’t have a language keyword.
Instead Xcode should be smart enough to omit the “… -> Void in” or at least the “ -> …”-part.
But again, this is a feature of your editor/IDE, not your language.

Thus I would recommend you to file a radar on it for Xcode to change its default auto-completion behavior. ;)

···

On 04 Jan 2016, at 13:45, QQ Mail via swift-evolution <swift-evolution@swift.org> wrote:

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 and the code also not aligned well.
I would like to write like this:

UIView.animateWithDuration(0.3,

    animations: { () -> Void in
        // animation code here
    },
    completion: { Bool -> Void in
        // completion code here
    }
)

It is possible, just every time you have to write it manually. It’s a little wast.
So I have a thought, since we already know this function is not well suit for trailing
closure, can we add a attribute to disable it, for example:

extension UIView {

    @disable_trailing_closure
    public static func animateWithDuration(duration:NSTimeInterval, animations:()->Void, completion:()->Void) {
        // implementations ...
    }
}

I also found another one have issue for this too. link: http://www.natashatherobot.com/swift-trailing-closure-syntax/
what do you think?

Best Regards

ChenYungui

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

JeromeD · January 5, 2016, 1:35pm

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 annotation to locally forbid trailing closure would add complexity to the language for no real advantage.

-1 for me thus.

Jerome

···

On 04 Jan 2016, at 19:52, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

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 closure syntax doesn't mean nobody should be able to use it. And other people using it shouldn't affect you.

-Kevin Ballard

On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:

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 and the code also not aligned well.
I would like to write like this:

UIView.animateWithDuration(0.3,

    animations: { () -> Void in
// animation code here
    },
    completion: { Bool -> Void in
// completion code here
    }
)

It is possible, just every time you have to write it manually. It’s a little wast.
So I have a thought, since we already know this function is not well suit for trailing
closure, can we add a attribute to disable it, for example:

extensionUIView {

@disable_trailing_closure
    public static func animateWithDuration(duration:NSTimeInterval, animations:()->Void, completion:()->Void) {
// implementations ...
    }
}

I also found another one have issue for this too. link: http://www.natashatherobot.com/swift-trailing-closure-syntax/
what do you think?

Best Regards

ChenYungui

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Dennis_Lysenko · January 5, 2016, 4:07pm

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 support it.

Personally, I think it should just be fixed in Xcode as well, but it's not
that simple.

···

On Tue, Jan 5, 2016, 8:35 AM Jérôme Duquennoy <swift-evolution@swift.org> wrote:

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 annotation to locally forbid trailing
closure would add complexity to the language for no real advantage.

-1 for me thus.

Jerome

On 04 Jan 2016, at 19:52, Kevin Ballard via swift-evolution < > swift-evolution@swift.org> wrote:

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 closure
syntax doesn't mean nobody should be able to use it. And other people using
it shouldn't affect you.

-Kevin Ballard

On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:

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 and the code also not aligned well.
I would like to write like this:

UIView.animateWithDuration(0.3,

    animations: { () -> Void in
// animation code here
    },
    completion: { Bool -> Void in
// completion code here
    }
)

It is possible, just every time you have to write it manually. It’s a
little wast.
So I have a thought, since we already know this function is not well suit
for trailing
closure, can we add a attribute to disable it, for example:

extensionUIView {

@disable_trailing_closure
    public static func animateWithDuration(duration:NSTimeInterval,
animations:()->Void, completion:()->Void) {
// implementations ...
    }
}

I also found another one have issue for this too. link:
http://www.natashatherobot.com/swift-trailing-closure-syntax/
what do you think?

Best Regards

ChenYungui

*_______________________________________________*
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · January 5, 2016, 6:47pm

FWIW, the algorithms used by Swift’s code completion in Xcode are part of sourcekit, which is included in Swift.org.

-Chris

···

On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org> 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 "light a fire" under the Xcode team; by introducing a new language feature they would be forced to support it.

Personally, I think it should just be fixed in Xcode as well, but it's not that simple.

Lily_Ballard · January 5, 2016, 6:59pm

Oh really? So I could actually go in there and fix it to stop generating closures that look like

    foo { () -> Void in
        <#code#>
    }

(the `() -> Void in` is rather pointless)

In that case, I suppose it makes sense to actually discuss proposed code completion changes on this list. On the subject of disabling trailing closure syntax, it might make sense to have Xcode not use it automatically when the function has 2 closure parameters (sometimes I do want the second closure to be trailing-closure, sometimes I don't, but it seems reasonable to err on the side of not having it be trailing-closure if there's more than 1 closure in the call).

-Kevin Ballard

···

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 <swift-evolution@swift.org> 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 "light a fire" under the Xcode team; by introducing a new language feature they would be forced to support it.
>
> Personally, I think it should just be fixed in Xcode as well, but it's not that simple.

FWIW, the algorithms used by Swift’s code completion in Xcode are part of sourcekit, which is included in Swift.org.

Dennis_Lysenko · January 5, 2016, 6:57pm

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 <clattner@apple.com> wrote:

> On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution < > swift-evolution@swift.org> 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 "light a fire" under the Xcode team;
by introducing a new language feature they would be forced to support it.
>
> Personally, I think it should just be fixed in Xcode as well, but it's
not that simple.

FWIW, the algorithms used by Swift’s code completion in Xcode are part of
sourcekit, which is included in Swift.org.

-Chris

Chris_Lattner · January 6, 2016, 6:52pm

No, it would be better to discuss it on swift-dev.

-Chris

···

On Jan 5, 2016, at 10:57 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

Chris, interesting tidbit. I wasn't aware of that. Is sourcekit considered to be within the scope of the swift-evolution mailing list?