<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&#39;m wondering if they&#39;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) -&gt; String)? = { [unowned self] someParam in ... }`</div><div>.. which doesn&#39;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&#39;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&#39;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 ~&quot;most programmers probably won&#39;t need/use them&quot;.</div><div><br></div><div>This from/about the language that has tacked on a whole statement (&#39;guard&#39;) 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&#39;s supposed to define the next decade+ of Apple and its (or more) community&#39;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 &#39;need&#39;/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&#39;t for Swift&#39;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&#39;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&#39;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&#39;s only one main chance/generation of feature addition with Swift, it should be relatively liberal/prescient.</div><div><br></div><div>Anyway, I&#39;ve said/rambled more than enough/than I&#39;m qualified to. TL;DR:/in summary, some things are relatively small (closure parameter labels probably won&#39;t define the future of the language) and some things.. aren&#39;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&#39;d be really curious to hear from core-esque people about their practical or lofty thoughts/feelings on this matter.</div></div>