> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution 
> <swift-evolution@swift.org> 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. `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 you replace *both* Int and Float with S you would get an error, but if you 
replace one you’ll only get an error if you do this within the same scope that 
your type is defined.

There’s nothing special happening here for the stdlib types vs. your own types. 
What you’re witnessing is shadowing. You can shadow names within deeper scopes, 
e.g. this is perfectly legal:

func MyOwnInt() {
  struct Int : ExpressibleByFloatLiteral {
    typealias FloatLiteralType = Double

    public init(floatLiteral value: FloatLiteralType) {
      self.value = value
    }

    var value: FloatLiteralType
  }
  let _: Int = 7.0
}


Mark

> 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> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <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
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to