[swift-users] another issue with tuples

[Aaron Bohannon]

This inconsistency is not limited to situations in which a tuple is a
non-temporary value:


class C {}

let _ = (C(), 3 as Int) as (Any, Int?)  // WORKS FINE
let _ = (C(), 3) as (C, Int) as (Any, Int?)  // TYPE ERROR
let _ = ((C(), 3), true).0 as (Any, Int?)  // TYPE ERROR


It can even cause the compiler to crash during type-checking on expressions
like the one below (which ought to be considered well-typed):


let _ = "a".isEmpty ? (C(), 3) as (C, Int) : (C(), 3) as (Any, Int?)


And it leads to some rather amusing output if you compile and run this code:


if (C(), 3 as Int) is (Any, Int?) {
  print("test is true")
} else {
  print("test is false")
}


The outcome will look something like this:





*test.swift:88:20: warning: 'is' test is always trueif (C(), 3 as Int) is
(Any, Int?) {                   ^test is false*



My bug report contains versions of all of those examples:

https://bugs.swift.org/browse/SR-2041

I used type casts above in order to make the origin of the problem as clear
as possible; however, it's also worth adding one more example to illustrate
that this problem is not limited to code that is contrived or uses tuples
in ways that are stylistically discouraged:


func returnPair() -> (C, Int) { return (C(), 3) }
var x: Int? = nil

x = returnPair().1  // WORKS FINE

(_, x) = returnPair()  // TYPE ERROR


- Aaron


On Wed, Jul 6, 2016 at 8:57 AM, Shane S <electro_alchemy at hotmail.com> wrote:

> 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 <neil.swift at faiman.org> 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 <swift-users at swift.org>
> 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 <
> swift-users at swift.org> 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
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160710/252d4ff0/attachment.html>