> 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. > >> On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution >> <[email protected]> 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? >>
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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
