> On 30 Jun 2016, at 21:20, Xiaodi Wu <[email protected]> wrote: > > On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > > Hello Swift community, > > > > The review of "SE-0111: Remove type system significance of function > > argument labels" begins now and runs through July 4. The proposal is > > available here: > > > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > > > > <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> > > > > * What is your evaluation of the proposal? > > -1 > > > * Is the problem being addressed significant enough to warrant a > > change to Swift? > > Yes, but I do not think that the proposed solution is the correct one. > Rather, one should aim for designing a proper tuple type. Right now, tuples > seem more like an afterthought even though they play a significant role in > the language. Proper tuple casting/extensions/tuple algebra will solve the > issues pointed out in this proposal, among other useful applications. > > Taras, I don't believe this proposal touches tuples in any way. IIUC, > argument lists are no longer tuples and have not been for a long time, and > there is no intention on the part of the core team to return to that state of > affairs.
Still, there is a clear correspondence between tuples and argument lists. I though that the model of functions as maps from tuples to tuples was very elegant, but I understand why this model was dropped. However tuples seem to be somehow misplaced right now, and this fact resonates through the entire language system (function types, enums, pattern matching etc.). I think one should stop and reconsider tuple status first to get a sense of a ‚grand strategy‘ for Swift. I am worried that small changes like this proposal attempt to deal with the ripples cast by a much deeper problem instead of the problem itself. As far as I am considered, there are two basic options. Either say, well, tuples were a nice idea, but it doesn’t really work out — and then consistently apply this to the entire language. Or, reinstate that tuples are a modelling construct on which a lot of language concepts are based and try to fix the underlaying limitations. Function arguments don’t need to be tuples formally. However, why not have a casting system that allows one to transform between function signatures and tuple types? That would certainly solve the deficients Swift is experiencing now as well as allow greater flexibility in the future. And orthogonally to the tuple topic, I think that argument labels carry meaningful semantics and are much more than just cosmetic devices. Accepting this proposal would make the language weird. The deeper connection between the semantics of the argument list and the exposed type would be disturbed. Hope any of this has made any sense :) > > > > * Does this proposal fit well with the feel and direction of Swift? > > I do not believe so > > > * If you have used other languages or libraries with a similar > > feature, how do you feel that this proposal compares to those? > > * How much effort did you put into your review? A glance, a quick > > reading, or an in-depth study? > > A glance > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
