New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type mismatch for tuple union types passed to tuple functions #827

Closed
zeddidragon opened this Issue Jan 29, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@zeddidragon

zeddidragon commented Jan 29, 2017

Steps to reproduce:

type Foo
  = Bar (String, Int)
  | Baz (Int, Int)

bar : Foo
bar = Bar ("Bar", 1)

derp : (a, Int) -> Int
derp (a, b) = b

herp = derp bar

Actual result:

-- TYPE MISMATCH ------------------------------------------------- UnionType.elm

The argument to function `derp` is causing a mismatch.

11|        derp bar
                ^^^
Function `derp` is expecting the argument to be:

    ( a, Int )

But it is:

    Foo

Expected result:
Program compiles, herp is 1

Since any instance of Foo is guaranteed to be a tuple where the second element is an Int, it should be reasonable to expect a function that only cares about the second element of the tuple to accept instances of Foo.

Version
Elm version 0.18.0 for OSX

@process-bot

This comment has been minimized.

Show comment
Hide comment
@process-bot

process-bot Jan 29, 2017

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

process-bot commented Jan 29, 2017

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

@zeddidragon zeddidragon changed the title from Type mismatch for tuple union types to Type mismatch for tuple union types passed to tuple functions Jan 29, 2017

@mgold

This comment has been minimized.

Show comment
Hide comment
@mgold

mgold Jan 30, 2017

Contributor

This behaves as designed and is unlikely to be changed. I can go into more depth if you ask on the mailing list.

Contributor

mgold commented Jan 30, 2017

This behaves as designed and is unlikely to be changed. I can go into more depth if you ask on the mailing list.

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Jan 30, 2017

Contributor

Max is right. I'm closing this issue.

Contributor

jvoigtlaender commented Jan 30, 2017

Max is right. I'm closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment