[Pitch] Adding in Optional Argument labels for completion handlers

Grant_Kemp · 2016-10-16T22:33:51.000Z

Hi all
A South African in London here and I have decided to make the jump to
trying to help Swift develop.

I was an android and web developer and swift converted me to iOS
programming which has become something that I love. I have built several
apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was
the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of the
method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow
question here:

stackoverflow.com

Xcode 8 :function types cannot have argument label breaking my build

ios, swift, xcode8, completionhandler

asked by UKDataGeek on 09:56AM - 21 Sep 16 UTC

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the
completionhandler method, which is confusing and not very readable.

func myMethod(_ completionhandler:(_ downloadedValue:String,_ isActive:
Bool, _ error:NSError)-> Void) {
//<<After doing some async method such as downloading from an API >>

completionhandler(myString, true, myError)

}
// INSTEAD: ideally the argument labels should be added optionally to
be called in the completion method such as below and using a Tuple-like
syntax to indicate that the method should have the labels

func myMethod(_ completionhandler:( downloadedValue:String, isActive:
Bool, error:NSError)-> Void) {

//<<After doing some async method such as downloading from an API >>

completionhandler(dowloadedValue:myString, isActive:true,
error:myError)

}

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !

···

--
Sent from my mobile

hooman · 2016-10-16T23:13:27.000Z

This is an unfortunate side effect of another important and necessary change: Making argument labels part of functions name. This means that closures (which are anonymous functions and lack a function name) now don’t have any place to keep the argument labels.

Using a labeled tuple as a single argument block could act as a workaround for now, but:

I think we really need to find the correct way to add back argument labels for closures. I strongly suspect such a change will be ABI breaking.

People (including myself) are getting some experience with actual implications and feel of lack of argument labels for anonymous functions. As far as I can tell, nobody likes this and it feels so very un-Swifty and a big step backwards.

Lets find a way to add back argument labels to closures for Swift 4.

···

On Oct 16, 2016, at 3:33 PM, Grant Kemp via swift-evolution <swift-evolution@swift.org> wrote:

Hi all
A South African in London here and I have decided to make the jump to trying to help Swift develop.

I was an android and web developer and swift converted me to iOS programming which has become something that I love. I have built several apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of the method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow question here:
ios - Xcode 8 :function types cannot have argument label breaking my build - Stack Overflow

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the completionhandler method, which is confusing and not very readable.
    func myMethod(_ completionhandler:(_ downloadedValue:String,_ isActive:Bool, _ error:NSError)-> Void) {
        //<<After doing some async method such as downloading from an API >>

        completionhandler(myString, true, myError)

    }
    // INSTEAD: ideally the argument labels should be added optionally to be called in the completion method such as below and using a Tuple-like syntax to indicate that the method should have the labels

    func myMethod(_ completionhandler:( downloadedValue:String, isActive:Bool, error:NSError)-> Void) {

        //<<After doing some async method such as downloading from an API >>

        completionhandler(dowloadedValue:myString, isActive:true, error:myError)

    }

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
--
Sent from my mobile
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · 2016-10-16T23:09:25.000Z

Welcome to the list! It seems the community and core team are in agreement
about your point. As mentioned previously, the core team has laid out a
two-step roadmap to restoring argument labels:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html

Hope that helps!

···

On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution < swift-evolution@swift.org> wrote:

Hi all
A South African in London here and I have decided to make the jump to
trying to help Swift develop.

I was an android and web developer and swift converted me to iOS
programming which has become something that I love. I have built several
apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was
the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of
the method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow
question here:

ios - Xcode 8 :function types cannot have argument label breaking my build - Stack Overflow

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the
completionhandler method, which is confusing and not very readable.

    func myMethod(_ completionhandler:(_ downloadedValue:String,_
isActive:Bool, _ error:NSError)-> Void) {
        //<<After doing some async method such as downloading from an API
>>

        completionhandler(myString, true, myError)

    }
    // INSTEAD: ideally the argument labels should be added optionally to
be called in the completion method such as below and using a Tuple-like
syntax to indicate that the method should have the labels

    func myMethod(_ completionhandler:( downloadedValue:String, isActive:
Bool, error:NSError)-> Void) {

        //<<After doing some async method such as downloading from an API
>>

        completionhandler(dowloadedValue:myString, isActive:true,
error:myError)

    }

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
--
Sent from my mobile
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Austin · 2016-10-16T23:16:53.000Z

It seems like that link should be added to the 'frequently proposed changes' page on the repo. I'll prepare a PR.

Austin

···

On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Welcome to the list! It seems the community and core team are in agreement about your point. As mentioned previously, the core team has laid out a two-step roadmap to restoring argument labels:

[swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Hope that helps!
On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all
A South African in London here and I have decided to make the jump to trying to help Swift develop.

I was an android and web developer and swift converted me to iOS programming which has become something that I love. I have built several apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of the method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow question here:
ios - Xcode 8 :function types cannot have argument label breaking my build - Stack Overflow

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the completionhandler method, which is confusing and not very readable.
    func myMethod(_ completionhandler:(_ downloadedValue:String,_ isActive:Bool, _ error:NSError)-> Void) {
        //<<After doing some async method such as downloading from an API >>

        completionhandler(myString, true, myError)

    }
    // INSTEAD: ideally the argument labels should be added optionally to be called in the completion method such as below and using a Tuple-like syntax to indicate that the method should have the labels

    func myMethod(_ completionhandler:( downloadedValue:String, isActive:Bool, error:NSError)-> Void) {

        //<<After doing some async method such as downloading from an API >>

        completionhandler(dowloadedValue:myString, isActive:true, error:myError)

    }

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
--
Sent from my mobile
_______________________________________________
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

xwu · 2016-10-16T23:23:36.000Z

Honestly, given that the detailed implementation is core team-approved, I
wonder if it ought to be just one of those rare pre-accepted proposals
instead. It may not be ABI impacting, but as a bugfix for a Swift 3
proposal there's a good argument it should go out in 3.x. My two cents
anyway.

···

On Mon, Oct 17, 2016 at 07:16 Austin Zheng <austinzheng@gmail.com> wrote:

It seems like that link should be added to the 'frequently proposed
changes' page on the repo. I'll prepare a PR.

Austin

On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

Welcome to the list! It seems the community and core team are in agreement
about your point. As mentioned previously, the core team has laid out a
two-step roadmap to restoring argument labels:

[swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Hope that helps!
On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all
A South African in London here and I have decided to make the jump to
trying to help Swift develop.

I was an android and web developer and swift converted me to iOS
programming which has become something that I love. I have built several
apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was
the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of
the method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow
question here:

ios - Xcode 8 :function types cannot have argument label breaking my build - Stack Overflow

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the
completionhandler method, which is confusing and not very readable.

    func myMethod(_ completionhandler:(_ downloadedValue:String,_
isActive:Bool, _ error:NSError)-> Void) {
        //<<After doing some async method such as downloading from an API
>>

        completionhandler(myString, true, myError)

    }
    // INSTEAD: ideally the argument labels should be added optionally to
be called in the completion method such as below and using a Tuple-like
syntax to indicate that the method should have the labels

    func myMethod(_ completionhandler:( downloadedValue:String, isActive:
Bool, error:NSError)-> Void) {

        //<<After doing some async method such as downloading from an API
>>

        completionhandler(dowloadedValue:myString, isActive:true,
error:myError)

    }

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
--
Sent from my mobile
_______________________________________________
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

Grant_Kemp · 2016-10-17T01:08:55.000Z

Thanks for the lovely welcome, and for sharing your perspectives.

It sounds like I am not alone on this.
In terms of the timings, given the vast number of:
- 3rd party libraries
- Open source apps
- Enterprise projects
that leverage completion handlers, and are steadfastly stripping their
argument labels away and wondering why this useful feature is gone. To
protect Swift's great reputation for swiftness, readibliity and clarity, I
would quite like to have those "stripping" out efforts avoided before
everyone has fully jumped to Swift 3.

I would quite like a fix included in the 3.x branch if its in any way
possible ( to agree with Xiaodi Wu) otherwise I will just have to bite the
bullet and know that there is sunshine on the horizon in the form of Swift
4.

Cheers

···

On Mon, 17 Oct 2016 at 00:23 Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Honestly, given that the detailed implementation is core team-approved, I
wonder if it ought to be just one of those rare pre-accepted proposals
instead. It may not be ABI impacting, but as a bugfix for a Swift 3
proposal there's a good argument it should go out in 3.x. My two cents
anyway.

On Mon, Oct 17, 2016 at 07:16 Austin Zheng <austinzheng@gmail.com> wrote:

It seems like that link should be added to the 'frequently proposed
changes' page on the repo. I'll prepare a PR.

Austin

On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

Welcome to the list! It seems the community and core team are in agreement
about your point. As mentioned previously, the core team has laid out a
two-step roadmap to restoring argument labels:

[swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Hope that helps!
On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all
A South African in London here and I have decided to make the jump to
trying to help Swift develop.

I was an android and web developer and swift converted me to iOS
programming which has become something that I love. I have built several
apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was
the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of
the method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow
question here:

ios - Xcode 8 :function types cannot have argument label breaking my build - Stack Overflow

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the
completionhandler method, which is confusing and not very readable.

    func myMethod(_ completionhandler:(_ downloadedValue:String,_
isActive:Bool, _ error:NSError)-> Void) {
        //<<After doing some async method such as downloading from an API
>>

        completionhandler(myString, true, myError)

    }
    // INSTEAD: ideally the argument labels should be added optionally to
be called in the completion method such as below and using a Tuple-like
syntax to indicate that the method should have the labels

    func myMethod(_ completionhandler:( downloadedValue:String, isActive:
Bool, error:NSError)-> Void) {

        //<<After doing some async method such as downloading from an API
>>

        completionhandler(dowloadedValue:myString, isActive:true,
error:myError)

    }

Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
--
Sent from my mobile
_______________________________________________
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

--

Sent from my mobile