It seems to me that we have a general problem with labels and every time we
have to push things around they break and we simply rip them out: first with
argument labels in closures and stores functions (sigh... :/, but we may get
labels back somehow there one day not too far from now hopefully) and now with
tuples.
P.S.:
I keep on thinking the urge of moving so much real world code over to it before
the language matured (were Swift 1 and 2 the right point to move production
code en masse?) did not leave enough time for breaking changes and discussions
about fixing remnants of choices made with Swift 1,2, and 3 may make big
discussions like this (and access control) here more and more prevalent, but I
may just be a laggard/Luddite ;).
Sent from my iPhone
> On 16 Jun 2017, at 07:04, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Fri, Jun 16, 2017 at 12:17 AM, David Hart <da...@hartbit.com> wrote:
>>
>>
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>
>>> On Thu, Jun 15, 2017 at 17:43 David Hart <da...@hartbit.com> wrote:
>>>>>> On 16 Jun 2017, at 00:41, David Hart <da...@hartbit.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 15 Jun 2017, at 19:28, Chris Lattner <sa...@nondot.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution
>>>>>> <swift-evolution@swift.org> o
>>>>>>>>>> >
>>>>>>>>>> > let (a : Int, b : Float) = foo()
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think it would be better if the compiler raised a warning whenever
>>>>>>>>>> you tried to redefine a builtin type.
>>>>>>>>>
>>>>>>>>> That’s essentially my preferred solution as well, as it gets to the
>>>>>>>>> root of the confusion.
>>>>>>>>>
>>>>>>>>> Naming a variable the same as a type should be similar to naming a
>>>>>>>>> variable the same as a reserved keyword and require backticks. (A
>>>>>>>>> previous suggestion to enforce capitalization falls down with full
>>>>>>>>> Unicode support and complicates interop where imported C structures
>>>>>>>>> might be lowercase and constants might be all caps.) No need to treat
>>>>>>>>> built-in types specially; it’s equally a problem with types imported
>>>>>>>>> from other libraries, which can be shadowed freely today. For full
>>>>>>>>> source compatibility this can be a warning instead of an error–should
>>>>>>>>> be sufficient as long as it’s brought to the user’s attention. In
>>>>>>>>> fact, probably most appropriate as a warning, since the _compiler_
>>>>>>>>> knows exactly what’s going on, it’s the human that might be confused.
>>>>>>>>
>>>>>>>> I kind of agree with all you say. But I also feel that tuple element
>>>>>>>> names in patterns are very rarely used and not worth the added
>>>>>>>> complexity and confusing. Going back to the old: “Would be add it to
>>>>>>>> Swift if it did not exist?”, I would say no.
>>>>>>>
>>>>>>> That was the standard for removing features before Swift 3, but with
>>>>>>> source compatibility the bar is now much higher.
>>>>>>
>>>>>> Completely agreed. My belief on this is that it is a legacy Swift 1
>>>>>> type system capability that no one uses. I have no data to show that
>>>>>> though.
>>>>>>
>>>>>>> Is the feature harmful?
>>>>>>
>>>>>> Yes, absolutely. The shadowing isn't the thing that bothers me, it is
>>>>>> that swift has a meaning for that very syntax in other contexts, and
>>>>>> that this is completely different meaning. People absolutely would get
>>>>>> confused by this if they encountered it in real code that they
>>>>>> themselves didn't write, and I'm not aware of any good (non theoretical)
>>>>>> use for it.
>>>>>>
>>>>>>> My point is, not on its own it isn’t: warning on variables shadowing
>>>>>>> types is sufficient to resolve the problems shown here.
>>>>>>
>>>>>> Again, my concern is that this is a confusing and misleading feature
>>>>>> which complicates and potentially prevents composing other features in
>>>>>> the future.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> How strange that we’re talking about this issue in a thread about
>>>>>>> SE-0110.
>>>>>>
>>>>>> This came up in the discussion about 110 because we were exploring
>>>>>> whether it was plausible to expand the function parameter grammar to
>>>>>> support destructuring in the position where a name goes. There are many
>>>>>> concerns about whether this is a good idea, but he existence of this in
>>>>>> the tuple destructuring pattern grammar is pretty much a showstopper.
>>>>>>
>>>>>>> If anything, the response to that proposal should be a cautionary tale
>>>>>>> that users can take poorly to removing features, sometimes in
>>>>>>> unanticipated ways.
>>>>>>
>>>>>> Agreed, it may be too late to correct this (certainly we can't outright
>>>>>> remove it in Swift 4 if someone is using it for something important).
>>>>>> However if it turns out that it really isn't used, then warning about it
>>>>>> in 4 and removing it shortly after may be possible.
>>>>>
>>>>> And I think its difficult to make the parallel between the two. SE-0110
>>>>> basically impacted everybody calling higher-order functions on Dictionary
>>>>> (+ more users from libraries like RxSwift), which makes an enormous
>>>>> proportion of the Swift community. On the other hand, despite the
>>>>> enormous amount of time I have sinked into learning, discussing and
>>>>> enjoying Swift, I never come upon the tuple element name syntax in
>>>>> patterns until Robert pointed to it out on twitter several weeks ago.
>>>>
>>>> By the way, I’m not attempting to deduce that nobody uses this feature by
>>>> the fact I didn’t know about it. But I think it’s one interesting
>>>> datapoint when comparing it to SE-0110.
>>>
>>>
>>> SE-0110, **in retrospect**, has had impacts on a lot of users;
>>> prospectively, it was thought to be a minor change, even after review and
>>> acceptance.
>>>
>>> Keep in mind that this proposed change would also eliminate inline tuple
>>> shuffle. For instance, the following code will cease to compile:
>>>
>>> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
>>> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>>> print(color)
>>> }
>>> f(color: x)
>>>
>>> It is an open question how frequently this is used. But like implicit tuple
>>> destructuring, it currently Just Works(TM) and users may not realize
>>> they’re making use of the feature until it’s gone.
>>
>> Xiaodi, can you explain to me what makes you think that your example piece
>> of code would be concerned by Chris' suggestion to remove tuple element
>> names from the pattern grammar? That's not what I understood.
>
> This issue was discussed in a thread beginning May 4 titled "Remove tuple
> shuffles" started by Robert Widmann. For a fuller exposition I recommend
> reading that (very long) thread. From his text:
>
> """
> A tuple-shuffle is an undocumented feature of Swift in which one can re-order
> the indices of a tuple by writing a pattern that describes a permutation in a
> syntax reminiscent of adding type-annotations to a parameter list:
>
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
>
> It can be used to simultaneously destructure and reorder a tuple:
>
> let tuple = (first: 0, second: (x: 1, y: 2))
> let (second: (x: b, y: c), first: a) = tuple
>
> It can also be used to map parameter labels out of order in a call expression:
>
> func foo(_ : (x : Int, y : Int)) {}
> foo((y: 5, x: 10)) // Valid
> """
>
> All of these examples demonstrate one and the same feature, which is the one
> that Chris is calling dubious; the pattern-matching syntax being mentioned
> here exists to enable this feature, and the proposal would be to rip it all
> out.
>
>>>>
>>>>>> -Chris
>>>>>>
>>>>>>>
>>>>>>>>>> `let (a : Int, b : Float) = foo()` is confusing but if you were to
>>>>>>>>>> use your own type (e.g., `struct S {}` and replace Int and Float
>>>>>>>>>> with S) you would get a compiler error. If the compiler warned you
>>>>>>>>>> that you were reassigning Int and Float, you’d probably avoid that
>>>>>>>>>> problem. Or, for a more extreme fix, we could make reassigning
>>>>>>>>>> builtin types illegal since there is pretty much no valid reason to
>>>>>>>>>> do that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution
>>>>>>>>>> > <swift-evolution@swift.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Sent from my iPad
>>>>>>>>>> >
>>>>>>>>>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution
>>>>>>>>>> >> <swift-evolution@swift.org> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <cantr...@pobox.com>
>>>>>>>>>> >>> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>> What’s the status of this Chris’s double parens idea below? It
>>>>>>>>>> >>> garnered some positive responses, but the discussion seems to
>>>>>>>>>> >>> have fizzled out. Is there something needed to help nudge this
>>>>>>>>>> >>> along?
>>>>>>>>>> >>>
>>>>>>>>>> >>> What’s the likelihood of getting this fixed before Swift 4 goes
>>>>>>>>>> >>> live, and the great wave of readability regressions hits?
>>>>>>>>>> >>
>>>>>>>>>> >> We discussed this in the core team meeting today. Consensus
>>>>>>>>>> >> seems to be that a change needs to be made to regain syntactic
>>>>>>>>>> >> convenience here. Discussion was leaning towards allowing (at
>>>>>>>>>> >> least) the parenthesized form, but more discussion is needed.
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> One (tangential) thing that came up is that tuple element names
>>>>>>>>>> >> in tuple *patterns* should probably be deprecated and removed at
>>>>>>>>>> >> some point. Without looking, what variables does this declare?:
>>>>>>>>>> >>
>>>>>>>>>> >> let (a : Int, b : Float) = foo()
>>>>>>>>>> >
>>>>>>>>>> > Another option would be to require let to appear next to each name
>>>>>>>>>> > binding instead of allowing a single let for the whole pattern. I
>>>>>>>>>> > personally find that much more clear despite it being a little bit
>>>>>>>>>> > more verbose.
>>>>>>>>>> >
>>>>>>>>>> >>
>>>>>>>>>> >> ?
>>>>>>>>>> >>
>>>>>>>>>> >> -Chris
>>>>>>>>>> >>
>>>>>>>>>> >> _______________________________________________
>>>>>>>>>> >> swift-evolution mailing list
>>>>>>>>>> >> swift-evolution@swift.org
>>>>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > swift-evolution mailing list
>>>>>>>>>> > swift-evolution@swift.org
>>>>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> swift-evolution mailing list
>>>>>>>>>> swift-evolution@swift.org
>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>> _______________________________________________
>>>>>>>>> swift-evolution mailing list
>>>>>>>>> swift-evolution@swift.org
>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution@swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
