[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko]

> On 30 Jun 2016, at 22:11, Austin Zheng <austinzheng at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/b672c7b8/attachment.html>