Skip to content
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 checking fails when iterating over C types #757

Open
yorickpeterse opened this issue Sep 4, 2024 · 0 comments
Open

Type checking fails when iterating over C types #757

yorickpeterse opened this issue Sep 4, 2024 · 0 comments
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers bug Defects, unintended behaviour, etc compiler Changes related to the compiler

Comments

@yorickpeterse
Copy link
Collaborator

Please describe the bug

Certain code patterns that involve C types, such as iterating over Array[Int32], result in a type checking error such as illustrated by this code example:

class async Main {
  fn async main {
    let a = [10 as Int32]

    a.into_iter.each(fn (a) {})
  }
}

This produces the following compile-time error:

test.inko:5:22 error(invalid-type): expected a value of type 'fn (Int32)', found 'fn (Int32)'

This error persists after adding an explicit type annotation to the a argument.

Briefly poking around the code it seems we hit the following code:

_ => false,

Printing the value compared against it seems we're comparing against a type parameter. I'm a bit surprised by that because I figured we'd be comparing against a type placeholder instead. Perhaps we just add a case where it allows the type check if the type parameter doesn't define any requirements, but I'd first like to know why we're comparing against a type parameter in the first place.

Operating system

Fedora

Inko version

main

@yorickpeterse yorickpeterse added accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers bug Defects, unintended behaviour, etc compiler Changes related to the compiler labels Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers bug Defects, unintended behaviour, etc compiler Changes related to the compiler
Projects
None yet
Development

No branches or pull requests

1 participant