[Accepted] SE-0111: Remove type system significance of function argument labels

Austin · July 9, 2016, 4:08pm

Sent from my iPhone

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

If you really want to promote local reasoning, write short methods and look at the function signature, where you can stick labels. Or use the type system or typealiases.

A better solution might be the compound function names that came up during both the review thread and this thread (e.g. let foo(with:for:) : (Int, Int) -> Bool = blah). Those were going to be added to the original proposal during private review, but were nixed. If someone feels strongly enough about the issue, they should submit a PR for a proposal amendment or a follow-up proposal.

···

On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

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

Taras_Zakharko1 · July 9, 2016, 10:31am

Well, now that function type and function signature are officially separate things, we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic. The proposal is incomplete in this regard. It attempts to solve one problem but actually shifts is elsewhere instead.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I am quite sure that they are discussing this internally :) Also, its weekend, let people get some rest!

···

On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPhone

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

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

Panajev · July 9, 2016, 6:03pm

Thank you Austin.

You asked for engagement with the community, I have provided as such. I did

not desire to do so originally,

Appreciated, I only felt the assumption of "not participating in the
original review" == "people not worth talking to" felt a bit patronising,
the way it was coming off, as it assumed quite a bit of explicit ill
intent.

You use labels when invoking the method using its original name, because

the labels are (almost always) prepositional phases that modify, and as
such only make sense in the context of, the original method name.

The concern is using the labels when calling a method passed to a function
where it is currently explicitly banned. More than reversing the proposal,
unless it is the only way to do so, it is finding a way to mandate the
argument labels when calling a callback method (or a method saved in a
closure type parameter which is essentially the same thing). I do not want
to go back to a era of passing two or more arguments to a function without
argument labels unless the language never had argument labels to begin with
or held them in high regards.

I will consider the rest of your points and re-read the original list
before posting in this thread again (unless somebody asks me a question :)).

···

On Sat, Jul 9, 2016 at 6:58 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Apologies, I meant to send this out to the list. If you wish to rebut my
points, you are welcome to cc the list with my blessing.

Best,
Austin

On Jul 9, 2016, at 10:55 AM, Goffredo Marocchi <panajev@gmail.com> wrote:

You asked for engagement with the community, I have provided as such.

Thank you.

On Sat, Jul 9, 2016 at 6:43 PM, Austin Zheng <austinzheng@gmail.com> > wrote:

On Jul 9, 2016, at 10:26 AM, Goffredo Marocchi <panajev@gmail.com> wrote:

Sorry for not participating, I do blame myself from missing how key that
change was. I can blame a very busy period, but that does not really matter.

I do think your attitude on this matter is a bit toxic and presumptuous
("people who couldn't be bothered to give feedback") though as if you are
looking down on other members of the list for this unforgivable sin.
Maybe it is not a matter of giving a damn about helping out the review of
the proposal although I can understand the frustration of people
disagreeing after the review period, but you should take it less personally
as it comes just out of care for the language and ideals even if it may be
as flawed as it can be.

You asked for engagement with the community, I have provided as such. I
did not desire to do so originally, as my participation in the review
thread degenerated into me making the same points again and again to
different people, and my participation in this thread would have become
more of the same, but here I am.

As for your other points, they are addressed abundantly in the original
thread, both by me and by multiple other people. Please in particular note
the delineation between argument labels used to identify the semantic
meaning of an argument, and argument labels as prepositional phrases which
modify the primary function name.

I imagine scenarios of callbacks, say for an image downloader or
something that ought to happen asynchronously, injected in a method,
stored, and then used when the asynchronous operation completed one way or
the other.
How does this promote local reasoning so much stressed by Apple itself
at WWDC when you have to jump through several hoops to have any idea what
the callbacks does or what parameters and in which order it needs them?

If you really want to promote local reasoning, write short methods and
look at the function signature, where you can stick labels. Or use the type
system or typealiases.

A better solution might be the compound function names that came up
during both the review thread and this thread (e.g. let foo(with:for:) :
(Int, Int) -> Bool = blah). Those were going to be added to the original
proposal during private review, but were nixed. If someone feels strongly
enough about the issue, they should submit a PR for a proposal amendment or
a follow-up proposal.

So, you think having code with multiple parameters passed with
obligatory labels mixed with methods where multiple parameters may/have to
be passed without argument labels and where the definition of the function
and its argument may well be outside of the method body improving clarity
and local reasoning or just easy to hand wave away with a "write shorter
methods" ?

Yes I do.

You use labels when invoking the method using its original name, because
the labels are (almost always) prepositional phases that modify, and as
such only make sense in the context of, the original method name.

You don't use labels when you erase the original context under which the
argument labels were defined by assigning a value of function type to a
variable whose name may or may not have any relation to the original method
name (again, this was discussed thoroughly in the review thread).

You can still use labels when defining your closure type arguments to a
function or method. Hence, "shorter methods", where the definition of the
relevant closure-type parameter is always a glance away.

I don't know why you are grousing at me, though. Once a proposal enters
the review stage (and to be clear, this proposal was introduced on behalf
of the core team), its fate is out of the hands of the author. What you
*can* do is to write and submit a counterproposal to amend and/or reverse
the effects of this one, if you deem it necessary. If your objective at
continuing this discussion is to convince the core team to re-review the
proposal, I'm sure that writing and submitting a counterproposal will be a
far more effective way of accomplishing that goal.

If this change simplified the compiler a lot it is a positive, but I
think there is a void that need to be addressed as I think that mandatory
argument labels are an important part of the language and the work by the
core team that carried them over from Objective-C and worked even ore on
those highlighting their importance in the road to Swift 3.0.
This situation now calls as much for fixing the discrepancy as much as
removing argument labels everywhere else, it unbalances the syntax IMHO.

The benefits to the compiler should be weighed against the negative
effects to every day's code and the bugs this may introduce in a safe by
default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution < >>> swift-evolution@swift.org> wrote:

I still say that this is the case where we do take a stand and do ask
for this proposal to be blocked and re-analised, I cannot believe that we
are going to be addingthis kind of incosistency to the language and take
readability/ease of local reasoning (which Apple stressed at the last WWDC
once again) away. The community and the core team just finished
bikeshedding a huge change to how API's are imported and how labels are
used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution < >>> swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site
. IMHO, the same principles that encourage the use of labels for "normal"
function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this
happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is
a astoundingly long list of features that will be removed because their
implementation is flawed, and whose fans have been calmed down with the
argument that they'll be re-added in an improved form later ;-)

_______________________________________________
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

frogcjn · July 9, 2016, 5:01pm

If you like, you can try to modify your code as you writes. It is crazy.

···

在 2016年7月10日，00:08，Austin Zheng via swift-evolution <swift-evolution@swift.org> 写道：

On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPhone

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

If you really want to promote local reasoning, write short methods and look at the function signature, where you can stick labels. Or use the type system or typealiases.

A better solution might be the compound function names that came up during both the review thread and this thread (e.g. let foo(with:for:) : (Int, Int) -> Bool = blah). Those were going to be added to the original proposal during private review, but were nixed. If someone feels strongly enough about the issue, they should submit a PR for a proposal amendment or a follow-up proposal.

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

owensd · July 11, 2016, 5:30am

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving across states with four kids, that prevented them from being able to engage during the official review period.

I’ve read through all of the posts that I see in my mailbox regarding this topic and I’ve yet to see any real answer to the concerns of tooling, typealias usage, closures, and code readability and maintainability concerns under this new proposal. This is the closest I’ve seen (from Douglas Gregor a few days ago):

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m just missing them, but I really don’t see those addressed and they are not mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work with resizing some image type. Today, if I did that, the tooling would give me auto-completion for all of the parameter labels and the code is very legible.

struct Size {
var x: Int
var y: Int
}

struct Image {
    var data: Data
    var size: Size
    // lots more properties...
}

typealias ImageResizedCallback = (original: Image, resized: Image) -> Void

func doResizeA(image: Image, completed: ImageResizedCallback) {
let newData = image.data
let newSize = image.size

    // do some work that's really slow...

    completed(original: image, resized: Image(data: newData, size: newSize))
}

func doResizeB(image: Image, completed: (original: Image, resized: Image) -> Void) {
let newData = image.data
let newSize = image.size

    // do some work that's really slow...

    completed(original: image, resized: Image(data: newData, size: newSize))
}

In either approach, `doResizeA` with a named callback or `doResizeB` with an explicit parameter type offer benefits that are lost under this proposal.

let someAsset = Image(data: Data(), size: Size(x: 100, y: 100))

doResizeA(image: someAsset, completed: { (original, resized) in
print("doResizeA - original: \(original), resized: \(resized)")
})

doResizeB(image: someAsset, completed: { (original, resized) in
print("doResizeB - original: \(original), resized: \(resized)")
})

Note that both `original` and `resized` get auto-completed for us here. This provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
let newData = image.data
let newSize = image.size

    // do some work that's really slow...

    completed(image, Image(data: newData, size: newSize))
}

This code is no longer self-documenting. I have no idea at looking at the call signature which order the images to `completed` should be.

Further, I get no help here when trying to use it:

doResizeC(image: someAsset) { (<#Image#>, <#Image#>) in
<#code#>
}

What do I label for the two images? This is a workflow regression. Yes, maybe the underlying model is more correct. However, this comes at a burden to actually authoring and maintaining the code. To me, that’s a truly unfortunate cost.

So now I probably write this:

doResizeC(image: someAsset) {
print("doResizeC1 - original: \($0), resized: \($1)")
}

Or, if I happen to know or look-up the order, I can fill in the labels myself:

doResizeC(image: someAsset, completed: { (original, resized) in
print("doResizeC2 - original: \(original), resized: \(resized)")
})

Further, we are able to turn runtime errors into compile-time checks when refactoring the signatures in the `doResizeA` and `doResizeB` functions - e.g. change the order of `original` and `resized` and you’ll get the compiler errors. This no longer happens under this proposal because the labels are erased. One way around that is to use types to solve this problem, but Swift provides no convenient way to have two `Image` types that share the same implementation but are considered as different types (sure, I could box them…).

I can get these benefits back, but now I need to introduce even more complexity into the system.

protocol ResizeCallbackType {
func resized(original: Image, resized: Image)
}

struct ResizeCallback : ResizeCallbackType {
    func resized(original: Image, resized: Image) {
        print("resized - original: \(original), resized: \(resized)")
    }
}

func doResizeD(image: Image, callback: ResizeCallbackType) {
    let newData = image.data
    let newSize = image.size

    // do some work that's really slow...

    callback.resized(original: image, resized: Image(data: newData, size: newSize))
}

doResizeD(image: someAsset, callback: ResizeCallback())

But who really wants to go through all the protocol effort just to get back to a place being able to allow for label usage again?

I agree that the proposal provides a “more correct” underlying model for Swift. However, before being approved, I would have really liked to have seen the above workflow and what I consider to be code readability and maintainability regressions addressed.

-David

···

On Jul 9, 2016, at 9:08 AM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

Chris_Lattner · July 14, 2016, 3:58am

Sent from my iPhone

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

Hi. The core team had a long discussion about this today. I will start a new thread to capture the discussion and update the community on the result of that. Thank for for all of the input (even after the review period). The core team really does care (even though everyone is insanely busy right now), we just can’t necessarily respond to every email in real time :-)

-Chris

···

On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

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

Panajev · July 9, 2016, 1:25pm

Well, now that function type and function signature are officially separate things,

I think we may have made a mistake in doing this and the implementation work is not done yet, so we are in time to reconsider things. Processes are not perfect, I do hope nobody gets too offended if I am suggesting we moved too hastily with this proposal without thinking everything through. It can happen.

we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic. The proposal is incomplete in this regard. It attempts to solve one problem but actually shifts is elsewhere instead.

... hence why I said that this proposal may have been accepted too hastily and if implementing it causes readability/usability/lack of context problems that is just as important as the hopeful benefits to the compiler. The compiler needs to be allowed to do a good job and helped too, but its job is to help us write better code and this proposal does not convince me as achieving that and is considered incomplete by at least a few others in this very thread too.

···

Sent from my iPhone

On 9 Jul 2016, at 11:31, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I am quite sure that they are discussing this internally :) Also, its weekend, let people get some rest!

On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPhone

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com> wrote:

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

_______________________________________________
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

Austin · July 11, 2016, 5:53am

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving across states with four kids, that prevented them from being able to engage during the official review period.

I hope your move went smoothly. More generally, there will always be people with good reasons for not being able to participate in the review process, but the procedure is set: one week of formal discussion, followed by a decision by the core team. If a proposal should be re-reviewed or amended, someone should submit (or at least draft) a follow-up proposal; none of the other proposals that have been accepted have been taken up for re-review by the core team based merely on reviews that were submitted after the review period ended (and there have been at least a few whose acceptance was very controversial).

I’ve read through all of the posts that I see in my mailbox regarding this topic and I’ve yet to see any real answer to the concerns of tooling, typealias usage, closures, and code readability and maintainability concerns under this new proposal. This is the closest I’ve seen (from Douglas Gregor a few days ago):

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m just missing them, but I really don’t see those addressed and they are not mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work with resizing some image type. Today, if I did that, the tooling would give me auto-completion for all of the parameter labels and the code is very legible.

Note that both `original` and `resized` get auto-completed for us here. This provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
let newData = image.data
let newSize = image.size

You can still have labels in the type: `completed: (original: Image, resized: Image)`.

    // do some work that's really slow...

    completed(image, Image(data: newData, size: newSize))

This is definitely a problem. I am considering writing a follow-up proposal that would allow for compound naming of values of function type, which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was brought up a couple of times during the review thread. (This was going to be part of the original proposal, but was removed for various reasons.)

···

On Jul 10, 2016, at 10:30 PM, David Owens II <david@owensd.io> wrote:

}

-David

Panajev · July 14, 2016, 6:49am

Sent from my iPhone

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

Hi. The core team had a long discussion about this today. I will start a new thread to capture the discussion and update the community on the result of that. Thank for for all of the input (even after the review period). The core team really does care (even though everyone is insanely busy right now), we just can’t necessarily respond to every email in real time :-)

-Chris

Hi Chris,

I do appreciate you are all working hard at closing perhaps the biggest update to your new programming language in its history, I also trust you care about community input.

This was one of the issues that were key for me in this language (even though some people do not miss parameter labels in other languages) and I also felt ashamed for not being able to take active part in the review and throwing toys out of the pram now, but it is such a small yet defining and clarifying feature I had to speak out.

Thank you for listening, talking again about it, and making a plan on how to move forward.

···

Sent from my iPhone

On 14 Jul 2016, at 04:58, Chris Lattner <clattner@apple.com> wrote:

On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com> wrote:

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

_______________________________________________
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

Taras_Zakharko1 · July 9, 2016, 1:48pm

Sent from my iPhone

Well, now that function type and function signature are officially separate things,

I think we may have made a mistake in doing this and the implementation work is not done yet, so we are in time to reconsider things. Processes are not perfect, I do hope nobody gets too offended if I am suggesting we moved too hastily with this proposal without thinking everything through. It can happen.

You should probably look into the original review thread. The core team made it very clear that the core changes in the compiler were made a long time ago and that the things were working different from what many (including me) thought. There were also some quite compelling reasons for not making label signature part of the type. Specifically, look for email by Jordan Rose

we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic. The proposal is incomplete in this regard. It attempts to solve one problem but actually shifts is elsewhere instead.

... hence why I said that this proposal may have been accepted too hastily and if implementing it causes readability/usability/lack of context problems that is just as important as the hopeful benefits to the compiler. The compiler needs to be allowed to do a good job and helped too, but its job is to help us write better code and this proposal does not convince me as achieving that and is considered incomplete by at least a few others in this very thread too.

The problem is much more complicated than seems at the first glance. Swift designers have opened a huge can of worms by making argument labels first-class features :) This moves the issues from the formal type domain to linguistic domain, and natural language is horribly messy. After some considerations, I believe that the move to separate type and signature is the simplest and probably the most reasonable solution (even though it makes me a bit sad), but we need some additional mechanism for dealing with closure arguments as well. Basically, we need something like a signature type/literal/syntax that enforces function signature, no matter the ‚kind‘ of function (func, variable, closure arg etc.).

Dr. Taras Zakharko

taras.zakharko@uzh.ch
IT Officer/Software Development

···

On 09 Jul 2016, at 15:25, Goffredo Marocchi <panajev@gmail.com> wrote:
On 9 Jul 2016, at 11:31, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

---------------------------------------------
Department of Comparative Linguistics
University of Zurich
Plattenstrasse 54, CH-8032 Zurich

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I am quite sure that they are discussing this internally :) Also, its weekend, let people get some rest!

On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPhone

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com <mailto:jon@jonshier.com>> wrote:

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site . IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

rudkx · July 11, 2016, 6:09am

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving across states with four kids, that prevented them from being able to engage during the official review period.

I hope your move went smoothly. More generally, there will always be people with good reasons for not being able to participate in the review process, but the procedure is set: one week of formal discussion, followed by a decision by the core team. If a proposal should be re-reviewed or amended, someone should submit (or at least draft) a follow-up proposal; none of the other proposals that have been accepted have been taken up for re-review by the core team based merely on reviews that were submitted after the review period ended (and there have been at least a few whose acceptance was very controversial).

I’ve read through all of the posts that I see in my mailbox regarding this topic and I’ve yet to see any real answer to the concerns of tooling, typealias usage, closures, and code readability and maintainability concerns under this new proposal. This is the closest I’ve seen (from Douglas Gregor a few days ago):

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m just missing them, but I really don’t see those addressed and they are not mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work with resizing some image type. Today, if I did that, the tooling would give me auto-completion for all of the parameter labels and the code is very legible.

Note that both `original` and `resized` get auto-completed for us here. This provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
    let newData = image.data
    let newSize = image.size

You can still have labels in the type: `completed: (original: Image, resized: Image)`.

    // do some work that's really slow...

    completed(image, Image(data: newData, size: newSize))

This is definitely a problem. I am considering writing a follow-up proposal that would allow for compound naming of values of function type, which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was brought up a couple of times during the review thread. (This was going to be part of the original proposal, but was removed for various reasons.)

In the meantime one option here would be to define a nested function that invokes the callback. It results in boilerplate, which is unfortunate, but would work:

func doResize
(
  image: Image,
  completed completedParam: (original: Image, resized: Image) -> Void
) {
  func completed(original: Image, resized: Image) {
    completedParam(original, resized)
  }

// do lots of work

completed(original: image, resized: Image(data: newData, size: newSize))
}

Mark

···

On Jul 10, 2016, at 10:53 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 10, 2016, at 10:30 PM, David Owens II <david@owensd.io <mailto:david@owensd.io>> wrote:

}

-David

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

owensd · July 11, 2016, 6:16am

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving across states with four kids, that prevented them from being able to engage during the official review period.

I hope your move went smoothly. More generally, there will always be people with good reasons for not being able to participate in the review process, but the procedure is set: one week of formal discussion, followed by a decision by the core team. If a proposal should be re-reviewed or amended, someone should submit (or at least draft) a follow-up proposal; none of the other proposals that have been accepted have been taken up for re-review by the core team based merely on reviews that were submitted after the review period ended (and there have been at least a few whose acceptance was very controversial).

Sure, the review period is fine. I think it’s unreasonable to say that questions, clarifications, or feedback should simply be ignored because it’s outside of the review window. If the feature is implemented and checked in, fine, but we’re still aways from there.

Regardless, my feedback was more about clarification on what is actually being changed for the workflow because I found no real answers in the proposal or the thread. I found where some concerns were made, but no real solutions to those concerns. Maybe I just overlooked them.

I’ve read through all of the posts that I see in my mailbox regarding this topic and I’ve yet to see any real answer to the concerns of tooling, typealias usage, closures, and code readability and maintainability concerns under this new proposal. This is the closest I’ve seen (from Douglas Gregor a few days ago):

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m just missing them, but I really don’t see those addressed and they are not mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work with resizing some image type. Today, if I did that, the tooling would give me auto-completion for all of the parameter labels and the code is very legible.

Note that both `original` and `resized` get auto-completed for us here. This provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
let newData = image.data
let newSize = image.size

You can still have labels in the type: `completed: (original: Image, resized: Image)`.

Labels that aren’t enforced or checked by the compiler are effectively worthless; they may as well be comments. This makes those labels allowed on typealiases equally as effective.

I also find it extremely strange that these labels will be allowed as source code that can never be verified or used in other places. It seems we are simply trading one set of inconsistencies for another.

    // do some work that's really slow...

    completed(image, Image(data: newData, size: newSize))

This is definitely a problem. I am considering writing a follow-up proposal that would allow for compound naming of values of function type, which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was brought up a couple of times during the review thread. (This was going to be part of the original proposal, but was removed for various reasons.)

Which just gets you back to this syntax for closures:

func doResizeB(image: Image, completed: (original: Image, resized: Image) -> Void)

Unless you really want to try and get parameter name syntax changed to match your example:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> Void)

Or maybe something else… I guess I will have to wait for the proposal.

-David

···

On Jul 10, 2016, at 10:53 PM, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 10, 2016, at 10:30 PM, David Owens II <david@owensd.io <mailto:david@owensd.io>> wrote:

owensd · July 11, 2016, 6:19am

That doesn’t solve anything; you still have to write the nested function, which means you still need to know what the order is. That’s only going to come through the documentation or non-compiler verified labels.

It also doesn’t help the call site for `doResize` - you’ll still get the non-descript `(Image, Image)` values.

-David

···

On Jul 10, 2016, at 11:09 PM, Mark Lacey <mark.lacey@apple.com> wrote:

In the meantime one option here would be to define a nested function that invokes the callback. It results in boilerplate, which is unfortunate, but would work:

func doResize
(
  image: Image,
  completed completedParam: (original: Image, resized: Image) -> Void
) {
  func completed(original: Image, resized: Image) {
    completedParam(original, resized)
  }

  // do lots of work

  completed(original: image, resized: Image(data: newData, size: newSize))
}

Austin · July 11, 2016, 6:24am

Unless you really want to try and get parameter name syntax changed to match your example:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> Void)

This is what I had in mind. You would be able to name a value of function type (whether it be a local variable, function argument, or property) with either a simple name (in which case there would be no labels at all), or a compound name with as many semicolons as arguments. Would you have any objection to this?

···

On Jul 10, 2016, at 11:16 PM, David Owens II <david@owensd.io> wrote:

Or maybe something else… I guess I will have to wait for the proposal.

-David

xwu · July 11, 2016, 6:24am

I wish the core team or the author of the proposal came to this thread and
engaged again with the community.

I'm not inclined to spend time engaging with people who couldn't be
bothered to give feedback during the week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving
across states with four kids, that prevented them from being able to engage
during the official review period.

I hope your move went smoothly. More generally, there will always be
people with good reasons for not being able to participate in the review
process, but the procedure is set: one week of formal discussion, followed
by a decision by the core team. If a proposal should be re-reviewed or
amended, someone should submit (or at least draft) a follow-up proposal;
none of the other proposals that have been accepted have been taken up for
re-review by the core team based merely on reviews that were submitted
after the review period ended (and there have been at least a few whose
acceptance was very controversial).

Sure, the review period is fine. I think it’s unreasonable to say that
questions, clarifications, or feedback should simply be ignored because
it’s outside of the review window. If the feature is implemented and
checked in, fine, but we’re still aways from there.

Regardless, my feedback was more about clarification on what is actually
being changed for the workflow because I found no real answers in the
proposal or the thread. I found where some concerns were made, but no real
solutions to those concerns. Maybe I just overlooked them.

I’ve read through all of the posts that I see in my mailbox regarding this
topic and I’ve yet to see any real answer to the concerns of tooling,
typealias usage, closures, and code readability and maintainability
concerns under this new proposal. This is the closest I’ve seen (from
Douglas Gregor a few days ago):

The core team’s intent is that one can add cosmetic labels to function
types, but that those labels are not (cannot be) used at the call site,
e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe
I’m just missing them, but I really don’t see those addressed and they are
not mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that
work with resizing some image type. Today, if I did that, the tooling would
give me auto-completion for all of the parameter labels and the code is
very legible.

Note that both `original` and `resized` get auto-completed for us here.
This provides great code clarity and insights. This is also
self-documenting code.

However, under this proposal as accepted (as I understand it), we are left
with this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
    let newData = image.data
    let newSize = image.size

You can still have labels in the type: `completed: (original: Image,
resized: Image)`.

Labels that aren’t enforced or checked by the compiler are effectively
worthless; they may as well be comments. This makes those labels allowed on
typealiases equally as effective.

I also find it extremely strange that these labels will be allowed as
source code that can never be verified or used in other places. It seems we
are simply trading one set of inconsistencies for another.

    // do some work that's really slow...

    completed(image, Image(data: newData, size: newSize))

This is definitely a problem. I am considering writing a follow-up
proposal that would allow for compound naming of values of function type,
which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`,
which was brought up a couple of times during the review thread. (This was
going to be part of the original proposal, but was removed for various
reasons.)

Which just gets you back to this syntax for closures:

func doResizeB(image: Image, completed: (original: Image, resized: Image)
-> Void)

Unless you really want to try and get parameter name syntax changed to
match your example:

func doResizeB(image: Image, completed(original:resized:): (Image, Image)
-> Void)

Or maybe something else… I guess I will have to wait for the proposal.

What makes sense to me is for the follow-on proposal to propose a notation
that permits mandatory external labels, while the for-your-reference-only
labels now left in the type annotation are treated as internal labels. That
is, for a function:

`func frobnicate(with foo: Int, and bar: Int)`

The corresponding notation could be

`let frobnicate(with:and:) : (foo: Int, bar: Int)`

···

On Mon, Jul 11, 2016 at 1:16 AM, David Owens II via swift-evolution < swift-evolution@swift.org> wrote:

On Jul 10, 2016, at 10:53 PM, Austin Zheng <austinzheng@gmail.com> wrote:
On Jul 10, 2016, at 10:30 PM, David Owens II <david@owensd.io> wrote:

-David

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

owensd · July 11, 2016, 7:17am

Unless you really want to try and get parameter name syntax changed to match your example:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> Void)

This is what I had in mind. You would be able to name a value of function type (whether it be a local variable, function argument, or property) with either a simple name (in which case there would be no labels at all), or a compound name with as many semicolons as arguments. Would you have any objection to this?

Would this compound name also affect how functions are referenced? I would assume no.

Also, how do typealiases work then? It's still desirable to not have to couple the labels there with the labels within the function declaration. So if:

typealias MyCallback = (original: Image, resized: Image) -> Void

Meant that these were equivalent:

func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> Void)

func doResizeB(image: Image, completed: MyCallback)

I probably wouldn't have any real objection.

-David

···

Sent from my iPhone

On Jul 10, 2016, at 11:24 PM, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 10, 2016, at 11:16 PM, David Owens II <david@owensd.io> wrote: