> On 30 Jun 2016, at 22:38, Austin Zheng <austinzh...@gmail.com> wrote: > > You might like the alternative I added > (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>). > It basically goes the other way: keep the semantic significance of labels, > and make them mean something by prohibiting converting between different > function types with the same types but different labels.
Yes, thats what I would vote for! I would also add the possibility of explicitly converting between different labels, as long as the types match, e.g.: battingAveragePredicate = sinkBattleship as ((ofHits: Int, forRuns: Int) -> Bool) or battingAveragePredicate = sinkBattleship as typeof(battlingAveragePredicate) (whatever the correct syntax for this would be). Best, t. > On Thu, Jun 30, 2016 at 1:36 PM, Taras Zakharko <taras.zakha...@uzh.ch > <mailto:taras.zakha...@uzh.ch>> wrote: > >> On 30 Jun 2016, at 22:11, Austin Zheng <austinzh...@gmail.com >> <mailto:austinzh...@gmail.com>> wrote: >> >> As for the label semantics, Swift's current behavior is actively misleading, >> please see the example in the prior email. There are no meaningful semantics >> in the label, because implicit conversion between differently-labeled >> function types means that there is no way to usefully enforce these >> invariants to begin with. > > That is a good point. I admit to not knowing this (I strongly expected that > labels would be semantically meaningful). But what exactly is the status of > the argument labels than in Swift? Just a documentation device for the > programmer and a hint for the compiler to do function dispatch? But if the > compiler indeed does dispatch on argument labels, then they are not > completely void of semantics, are they? As I mentioned before, I think the > problem here is much deeper. > > The state of affairs I would prefer is something along these lines: > > 1. Labels are semantically meaningful > 2. There is an explicit casting system for function signatures > 3. This casting system should be in close correspondence to tuples. The > "function argument lists look sort of like tuples“ is a very compelling > reason actually, because of the principle of the least surprise. If I have > two things in the language that look very similar, then its very confusing if > they exhibit very different behaviour. Again, I am not proposing that one > goes back to model functions in terms of tuples. But as long as there is a > surface resemblance (and an obvious morphisms between the two), at least some > aspects of their design should be kept in sync. > > But again, this touches on some deep design decisions for the language, so I > — as an amateur — don’t feel in my plate discussing this here. I believe that > there currently might be some inconsistencies in the language design that > should be sealed with (but maybe they are no inconsistencies at all and I > simply have false expectations). > > Best, > > Taras > >> >> On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution >>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
