On Mon, Jul 11, 2016 at 1:16 AM, David Owens II via swift-evolution < [email protected]> wrote:
> > On Jul 10, 2016, at 10:53 PM, Austin Zheng <[email protected]> wrote: > > > 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). > > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
