> On Jul 10, 2016, at 10:53 PM, Austin Zheng via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jul 10, 2016, at 10:30 PM, David Owens II <da...@owensd.io >> <mailto:da...@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). > >> >> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution