> On 16 Jun 2017, at 08:04, Xiaodi Wu <xiaodi...@gmail.com> 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.
Oh yes, I remember that thread and those points now. Thanks for the reminder.
The two questions to ask now are:
• How useful/used are those tuple shuffling features? The reordering features
feels like a very surprising feature (in a negative way) to me.
• If people really depend of some of these, can the tuple element name syntax
in patterns be plugged out without removing the reordering? Seems technically
feasible, just not sure how easy in the compiler code.
Now that this discussions comes back to my mind, the feature I have a real
issue with is basically any syntax that allows you to write a label name after
a colon in a tuple context, because we naturally expect to see types there.
>>>>
>>>>>> -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
