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 inference #18

Open
jdpage opened this issue Dec 11, 2017 · 2 comments
Open

Type inference #18

jdpage opened this issue Dec 11, 2017 · 2 comments

Comments

@jdpage
Copy link
Collaborator

jdpage commented Dec 11, 2017

I think it could be helpful to provide simple type inference for let and for statements, to make the language a little cleaner. So the following would be allowed:

let x: u8 = 7
let y = x  --[[ y is u8 ]]

let z: [u16; 4] = [1, 2, 3, 4]
for w in z do
    --[[ w is u16 ]]
end

Since the type-checker has to derive what y and w should be anyway, it should be simple to allow it to just assume the type. (One might want y or w to be a longer type, but we'd still have to derive u8 and u16 respectively to determine which types are longer.)

@jdpage jdpage mentioned this issue Dec 11, 2017
28 tasks
@woodrowbarlow
Copy link
Collaborator

i am okay with this.

i only hesitate because i think explicit types always make code easier to read, but type inference does make refactors cleaner. so i'm on board.

@jdpage
Copy link
Collaborator Author

jdpage commented Dec 14, 2017

I definitely think that we should have explicit types in the function signatures, for what it's worth. I don't really see us having more complicated type inference than what I'm suggesting above.

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

No branches or pull requests

2 participants