[swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Xiaodi Wu]

On Mon, Jul 11, 2016 at 1:16 AM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jul 10, 2016, at 10:53 PM, Austin Zheng <austinzheng at gmail.com> wrote:
>
>
> On Jul 10, 2016, at 10:30 PM, David Owens II <david at owensd.io> wrote:
>
>
> I wish the core team or the author of the proposal came to this thread and
> engaged again with the community.
>
>
> I'm not inclined to spend time engaging with people who couldn't be
> bothered to give feedback during the week-long official review period.
>
>
> Not all people "couldn’t be bothered” but had life events, such as moving
> across states with four kids, that prevented them from being able to engage
> during the official review period.
>
>
> I hope your move went smoothly. More generally, there will always be
> people with good reasons for not being able to participate in the review
> process, but the procedure is set: one week of formal discussion, followed
> by a decision by the core team. If a proposal should be re-reviewed or
> amended, someone should submit (or at least draft) a follow-up proposal;
> none of the other proposals that have been accepted have been taken up for
> re-review by the core team based merely on reviews that were submitted
> after the review period ended (and there have been at least a few whose
> acceptance was very controversial).
>
>
> Sure, the review period is fine. I think it’s unreasonable to say that
> questions, clarifications, or feedback should simply be ignored because
> it’s outside of the review window. If the feature is implemented and
> checked in, fine, but we’re still aways from there.
>
> Regardless, my feedback was more about clarification on what is actually
> being changed for the workflow because I found no real answers in the
> proposal or the thread. I found where some concerns were made, but no real
> solutions to those concerns. Maybe I just overlooked them.
>
> I’ve read through all of the posts that I see in my mailbox regarding this
> topic and I’ve yet to see any real answer to the concerns of tooling,
> typealias usage, closures, and code readability and maintainability
> concerns under this new proposal. This is the closest I’ve seen (from
> Douglas Gregor a few days ago):
>
> The core team’s intent is that one can add cosmetic labels to function
> types, but that those labels are not (cannot be) used at the call site,
> e.g.,
>
>
> Do you have specific post in mind that addresses the these concerns? Maybe
> I’m just missing them, but I really don’t see those addressed and they are
> not mentioned in the proposal at all.
>
> Let’s say I want to model a problem regarding some library functions that
> work with resizing some image type. Today, if I did that, the tooling would
> give me auto-completion for all of the parameter labels and the code is
> very legible.
>
> Note that both `original` and `resized` get auto-completed for us here.
> This provides great code clarity and insights. This is also
> self-documenting code.
>
> However, under this proposal as accepted (as I understand it), we are left
> with this:
>
> func doResizeC(image: Image, completed: (Image, Image) -> Void) {
>     let newData = image.data
>     let newSize = image.size
>
>
> You can still have labels in the type: `completed: (original: Image,
> resized: Image)`.
>
>
> Labels that aren’t enforced or checked by the compiler are effectively
> worthless; they may as well be comments. This makes those labels allowed on
> typealiases equally as effective.
>
> I also find it extremely strange that these labels will be allowed as
> source code that can never be verified or used in other places. It seems we
> are simply trading one set of inconsistencies for another.
>
>
>
>     // do some work that's really slow...
>
>     completed(image, Image(data: newData, size: newSize))
>
>
> This is definitely a problem. I am considering writing a follow-up
> proposal that would allow for compound naming of values of function type,
> which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`,
> which was brought up a couple of times during the review thread. (This was
> going to be part of the original proposal, but was removed for various
> reasons.)
>
>
> Which just gets you back to this syntax for closures:
>
> func doResizeB(image: Image, completed: (original: Image, resized: Image)
> -> Void)
>
> Unless you really want to try and get parameter name syntax changed to
> match your example:
>
> func doResizeB(image: Image, completed(original:resized:): (Image, Image)
> -> Void)
>
> Or maybe something else… I guess I will have to wait for the proposal.
>

What makes sense to me is for the follow-on proposal to propose a notation
that permits mandatory external labels, while the for-your-reference-only
labels now left in the type annotation are treated as internal labels. That
is, for a function:

`func frobnicate(with foo: Int, and bar: Int)`

The corresponding notation could be

`let frobnicate(with:and:) : (foo: Int, bar: Int)`



> -David
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/a3fd680a/attachment.html>