The section you are referencing is regarding ‘assignment’; however, in the 
example below we aren’t talking about assignment, this is 
'constant-declaration', which is different than a ‘parenthesized expression’.

But overall I get it, and I think I’m trending toward the same conclusion you 
reached re: checking the full type of the identifier -vs- comparing the types 
of the constituent elements - interesting stuff!

Shane


On Jul 6, 2016, at 7:34 AM, Neil Faiman 
<[email protected]<mailto:[email protected]>> wrote:

The language reference says that “Assignment is performed from each part of the 
value to the corresponding part of the expression. A String value can be 
assigned to a String, and a () -> Int value can be assigned to a () throws -> 
Int, so one would reasonably expect that both tuple assignments would work.

My hunch would be that the compiler has two different code paths for an 
assignment whose RHS is an identifier and an assignment whose RHS is a  
parenthesized-expression; that in the first case starts about by asking whether 
the RHS type is the same or a subtype of the LHS type, and reporting an error 
when it isn’t, but that in the second case, it starts with an 
element-by-element type comparison, which succeeds.

Regards,

Neil

On Jul 6, 2016, at 9:55 AM, Shane S via swift-users 
<[email protected]<mailto:[email protected]>> wrote:

Aaron this works for me in both Swift 2.2 and Swift 3 provided that you remove 
the ‘throws’ keyword.

What seems odd to me is not the first assignment, but rather the second that 
_allows_ the use of ‘throws’ when t.1 (i.e. f) does not throw - is your concern 
the same?

Shane


On Jul 5, 2016, at 10:48 PM, Aaron Bohannon via swift-users 
<[email protected]<mailto:[email protected]>> wrote:

Yesterday, it was pointed out that a variable name referring to a tuple cannot 
be used as a pattern.  I have noticed another sort of inconsistency in how 
tuples are treated when they are referenced by name:

func f() -> Int { return 5 }

let t = ("a", f)

let _: (String, () throws -> Int) = t  // type error
let _: (String, () throws -> Int) = (t.0, t.1)  // OK

This situation leads to a different sort of type error; however, the error 
seems equally unwarranted.  I can't see any good reason for a well-typed 
program to become ill-typed when `(t.0, t.1)` is replaced with `t` (assuming 
`t` is a pair).

Should I file a separate bug for the specific example above?

- Aaron
_______________________________________________
swift-users mailing list
[email protected]<mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
[email protected]<mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-users


_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to