-
Notifications
You must be signed in to change notification settings - Fork 112
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
Cannot create generic methods that return arrays of the generic type #512
Comments
Yes, it is a known issue at this time, because generics for a function are currently resolved only on their arguments, not on return types. We'd need a smarter bidirectional type inference to do that. We've had another issue related to inference of generics but I couldn't find it quickly now, and the conclusion I'm getting to is that it's probably best to allow the user to specify the type values explicitly instead of trying to be too smart in inference — that is, for the case you describede, instead of |
Maybe we can copy Rust's syntax for specifying generics ( Though, for teal |
This could be unrelated, but on the topic of type inference, it would be really neat if we could do things like this:
That is - if teal could infer the entire type values for a function given as an inline argument to a function. Currently you have to do this:
|
I have improved flow checking of function return values. The example in this issue now type checks: local function get_foos<T>():{T}
return {}
end
local foos:{integer} = get_foos()
print(foos) Teal is now able to make Thank you for the report, @svermeulen ! |
Brilliant. Thank you! |
This involved some pretty serious surgery to the function call checking
implementation! Please give it a spin on your codebase and let me know if
the code in the latest master has caused any regressions!
|
Ok I updated teal to master and did a type check of the 344 tl files in my project. It found a bunch of new errors, all of which were valid (which means that the previous version I had missed those somehow) but there was one in particular that seems like a possible regression. I've reported it here: #582 |
Good! That means I'm making the type checker smarter! By any chance do you have a way to isolate any of those errors that are now caught? I'd love to add them to the test suite, if they're new patterns I don't happen to have covered in tests (I didn't manage to get many new tests in).
Yes, it's definitely a regression. I have a general idea of what's going on, I think it should be possible to get to a fix with your testcase in #582. Thanks again! |
This builds:
However, the following does not:
With error:
in local declaration: foos: got {<invalid type>}, expected {integer}
Is this a known limitation or is there a better way to handle this case?
For now I'm doing this:
The text was updated successfully, but these errors were encountered: