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 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?
I agree that this proposal should be re-evaluated. Apple stressed readability at WWDC this year, and taking away the argument labels takes away readability. Also, I think it fails these two important tests:
* Is the problem being addressed significant enough to warrant a change to Swift?
No. It is not a major problem, and it can easily be worked around. Also, this change could break some source code, requiring changes to existing code.
* Does this proposal fit well with the feel and direction of Swift?
No. As stated above, it decreases code readability, which was stressed at WWDC.
On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <firstname.lastname@example.org> wrote: