Type check mismatch
See original GitHub issueCompiler version
3.0.0
Minimized code
case class G[A, X[_]](x: X[A])
enum Boxes[A]:
case IntBox(a: Int)
case StringBox(a: String)
import Boxes._
def f(i: Int): G[Int, Boxes] =
val box = IntBox(i)
return G(box)
Output
Found: (box : Boxes[Nothing])
Required: Boxes[Int]
return G(box)
Expectation
Behave the same as the in-line version (which does work)
...
def g(i: Int): G[Int, Boxes] =
return G(IntBox(i))
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
VBA Type Mismatch Error - The Ultimate Guide
A VBA Type Mismatch Error occurs when you try to assign a value between two different variable types. The error appears as “run-time...
Read more >I get a message about data type mismatch
I get a message about data type mismatch ... This error indicates that Access cannot match an input value to the data type...
Read more >Type checking errors
This section lists all errors that can occur when type checking is performed. Error: Type mismatch: This can happen in many cases: The...
Read more >Type mismatch error when types are verified
I get a type mismatch error when calling OutputEntry with the first ... fine and does get called inside of that type checking...
Read more >Understanding Elm's Type Mismatch Error
If you see a function in a Type Mismatch error, you'll want to check that the function has been passed all its arguments...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This is, as I understand it, fundamentally down to the fact that the type system has subtyping.
Maybe taking into account future uses is something useful to do, especially in trivial cases like this. Going along that, the error messaging could be improved here:
Found: (box : Boxes[Nothing])
implies this type was given by the user. In more difficult cases where the “taking into account future uses” fails, a clearer error message could read:This may significantly improve the comfort, while avoiding breaking the equivalence stated above as much as possible.