> 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
>> <mailto:sa...@nondot.org>> wrote:
>>
>>
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution
>> <swift-evolution@swift.org <mailto: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.
>> -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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:
>>>> >>
>>>> >>
>>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <cantr...@pobox.com
>>>> >>> <mailto: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 <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 <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 <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
