> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> > 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()
>
>
> 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.
> `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] <mailto:[email protected]>> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution
> >> <[email protected] <mailto:[email protected]>> wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <[email protected]
> >>> <mailto:[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] <mailto:[email protected]>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <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
