> On Jul 10, 2016, at 10:53 PM, Austin Zheng via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jul 10, 2016, at 10:30 PM, David Owens II <[email protected]
>> <mailto:[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.)
In the meantime one option here would be to define a nested function that
invokes the callback. It results in boilerplate, which is unfortunate, but
would work:
func doResize
(
image: Image,
completed completedParam: (original: Image, resized: Image) -> Void
) {
func completed(original: Image, resized: Image) {
completedParam(original, resized)
}
// do lots of work
completed(original: image, resized: Image(data: newData, size: newSize))
}
Mark
>
>> }
>>
>> -David
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
