>
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution
> <[email protected]> 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.
-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
>>>> > <[email protected]> wrote:
>>>> >
>>>> >
>>>> >
>>>> > Sent from my iPad
>>>> >
>>>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution
>>>> >> <[email protected]> wrote:
>>>> >>
>>>> >>
>>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <[email protected]> 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
>>>> >> [email protected]
>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> >
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > [email protected]
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
