> 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. `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
