-
Notifications
You must be signed in to change notification settings - Fork 240
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
typechecker: Type check generic functions independently of their use #1389
Comments
Skipping the last one as it's likely because of a typecheck weirdness regarding return types (are we actually checking them?), I don't see what's wrong with the |
Hm, interesting. Maybe I'm just primed differently by other languages, but the same would not pass type checking in: But maybe the desire for a generic function to be "correct in abstract" is not as universal as I thought. Edit: Actually now that I think about it, imagine the same scenario across library boundaries. Wouldn't this be super weird? You call a generic function and suddenly there is a type error in the library? |
We initially did check the generic function on its own (we still do), but not everything can be resolved like that since we're somewhat closer to C++ in this; e.g. comptime expressions depending on the concrete type ( |
Re the error placement, yeah that could use some work, for instance, we could give you a trace of why the call happened. |
As a sidenote, I do think we should check things that are actually constrained somehow, by traits or other requirements, and make them invariants inside the generic function. |
Just for reference, this doesn't compile - so something is specifically wrong about returning None there, it is not that we aren't checking at all: fn to_minus_42<T>(anon a: Optional<T>) -> T {
return "String"
}
fn main() {
to_minus_42(Some(42))
} |
Does returning None in a normal function that's supposed to return...say, i32 cause an error? |
Ah thats it 😅 Even this typechecks: fn please_not_none(anon a: i64) -> i64 {
return None
}
fn main() {
please_not_none(42)
} I created #1390 let this issue be about generic return type checking / error reporting and not this |
It looks to me like we aren't checking generic functions "on their own". Instead, we only check them with type variables filled in at their call sites. This leads to quite strange error reporting and in some cases even C++ that doesn't compile.
Currently, writing this is not an error:
However, this is:
Also notice where it is reported:
Lastly, consider this case, which will type check but doesn't compile:
The text was updated successfully, but these errors were encountered: