<div>On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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?:<br>
><br>
> let (a : Int, b : Float) = foo()<br>
<br>
<br>
I think it would be better if the compiler raised a warning whenever you tried to redefine a builtin type.</blockquote><div><br></div><div>That’s essentially my preferred solution as well, as it gets to the root of the confusion.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> `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.<br>
<br>
<br>
> On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
> Sent from my iPad<br>
><br>
>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" target="_blank">cantrell@pobox.com</a>> wrote:<br>
>>><br>
>>> 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?<br>
>>><br>
>>> What’s the likelihood of getting this fixed before Swift 4 goes live, and the great wave of readability regressions hits?<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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?:<br>
>><br>
>> let (a : Int, b : Float) = foo()<br>
><br>
> 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.<br>
><br>
>><br>
>> ?<br>
>><br>
>> -Chris<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>