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

[Austin Zheng]

This is a false dichotomy. The language can support tuples without
requiring that function application be modeled in terms of tuples. That
ship has sailed long ago, and there is no reason to revisit it without a
compelling reason (and "function argument lists look sort of like tuples"
is not to me compelling).

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.

On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 30 Jun 2016, at 21:20, Xiaodi Wu <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> wrote:
>
>>
>> > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution <
>> 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
>> >
>> >       * 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/4ff391c6/attachment.html>