<div dir="ltr">Per <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html">https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html</a>, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I'm wondering if they're coming back (syntactically) any time soon?<div><br></div><div>Other than being in the spirit of Swift in general (safe APIs, first class closures/functions), with the lack of optional protocol requirements the only way to achieve something similar is..</div><div>`lazy var someFunc: ((someParam: String) -> String)? = { [unowned self] someParam in ... }`</div><div>.. which doesn't compile anymore.</div><div><br></div><div>–––––––––––––––––––––––––––––––––––––––––––</div><div><br></div><div>As a related aside, I love Swift, and as it gains more core functionality (e.g. KeyPaths) I love it even more. However I'm concerned that the systems (frameworks <i>or</i> apps) I/others create on top of such functionality are only as good as their APIs, which are often held back by the lack of relevant features – </div><div>optional protocol requirements, within-module access (or at least, <i>visibility</i>) control (e.g. ~protected), explicit/arbitrary namespaces, abstract classes, currying, generalised existentials, factory initialisers, closure parameter labels, etc.</div><div>– and it's concerning to read through swift-evolution and find a general pattern of these features being postponed or worse, rejected, not because of clear alternatives to producing the same <i>safe and expressive/explicit</i> APIs they facilitate, but because ~"most programmers probably won't need/use them".</div><div><br></div><div>This from/about the language that has tacked on a whole statement ('guard') for inverse conditionals.</div><div>This from/about the language that is/has successfully popularised protocol oriented programming, custom/overloaded operators, and ADTs.</div><div>This from/about the language that's supposed to define the next decade+ of Apple and its (or more) community's software, as well as programming education.</div><div><br></div><div>I think that if/when Swift accomplishes world domination (cc: Lattner), it will find that the world is more diverse than has been let on, and the only practical limit to what people will 'need'/find useful will be what Swift was able to integrate safely/elegantly.</div><div><br></div><div>None of this would matter of course, or at least not so much, if it wasn't for Swift's nearing target of ABI stability. Someone absolutely do feel free to console me/tell me that all of these kinds of things (and things that haven't been thought of yet; state of the art is a quickly moving target after all..) could be added later if the community changes its mind, but if not, that's scary. I understand the dangers of feature creep and kitchen-sinkage, but C++ (e.g/etc.; TypeScript?) got the way it is by reckless feature addition over multiple generations unchecked by ABI stability requirements. Surely if there's only one main chance/generation of feature addition with Swift, it should be relatively liberal/prescient.</div><div><br></div><div>Anyway, I've said/rambled more than enough/than I'm qualified to. TL;DR:/in summary, some things are relatively small (closure parameter labels probably won't define the future of the language) and some things.. aren't; I hope that everything is being done to ensure that Swift can dominate the world (and its diverse use cases)<i> currently</i> as well as hold that spot when the standards/state of the art changes. I'd be really curious to hear from core-esque people about their practical or lofty thoughts/feelings on this matter.</div></div>