> On Jul 10, 2016, at 10:30 PM, David Owens II <[email protected]> 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).
>
> 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)`.
>
> // 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.)
> }
>
> -David
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
