[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Mathew Huusko V]

Per
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html,
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?

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..
`lazy var someFunc: ((someParam: String) -> String)? = { [unowned self]
someParam in ... }`
.. which doesn't compile anymore.

–––––––––––––––––––––––––––––––––––––––––––

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 *or* 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 –
optional protocol requirements, within-module access (or at least,
*visibility*) control (e.g. ~protected), explicit/arbitrary
namespaces, abstract classes, currying, generalised existentials, factory
initialisers, closure parameter labels, etc.
– 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 *safe and expressive/explicit* APIs
they facilitate, but because ~"most programmers probably won't need/use
them".

This from/about the language that has tacked on a whole statement ('guard')
for inverse conditionals.
This from/about the language that is/has successfully popularised protocol
oriented programming, custom/overloaded operators, and ADTs.
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.

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.

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.

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)* currently* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170804/2b063415/attachment.html>