-
Notifications
You must be signed in to change notification settings - Fork 786
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
Statically resolved type parameters don't propagate correctly, and hashed typenames like ^?9104 in unjust compile error #3508
Comments
@abelbraaksma Is there a repro without using |
@dsyme, yes, it happens with basically any method. But perhaps more likely with Example with op_Implicit:
Error:
Example with a regular method (this code, however, is deliberately wrong, but it shows the error is faulty, or at the very least hard to understand):
Error:
Of course, in the latter example, the member constraint is actually missing in the declaration of It helps perhaps to show what I tried to achieve. I wanted to create a generic function with statically resolved type parameters, that can do a range check (and some other checks, removed for brevity) on a given type. Just some ducktyping, essentially. But for ease of use, I also hoped to be able to parameterize only the source type, as the target type would be known by the compiler from its argument. Here's what I thought ought to work, the original idea (note the missing type declarations on the declaration of
I think this code should compile, but it throws a compile error on the last line:
Which made add such method (a dummy to do a conversion to an unknown target type), which ultimately led to #3509 (crash of FSC). I think, still, that the code above is valid and that the FS0043 error should not be raised. I have meanwhile found a workaround: Since such code is only possible with using either So, given the same example, this works:
It compile fine and runs fine when used. That still leaves us with the two findings here:
|
I see that this has been in the backlog for a while, and just want to bump it up if possible. I find that I run into it very easily when I try to do basic generic arithmetic, such as:
|
Treating this as a duplicate of #385 |
Reopening this one, as the duplicate was resolved, but that resolution did not fix this issue. The original code still raises the weird numbered types in exceptions. |
I must admit, I have seen this error before, but I have always managed to somehow mysteriously fix it, but now I'm stymied and I decided to report it.
The issue is: compile errors are raised on missing type parameters, but the error shows a garbled name which makes it virtually impossible to understand what is going on.
In addition, in this particular scenario, the error is incorrect, I think this source code should compile.
Repro steps
To repro, just copy the following code and try to compile, the error is on the last line.
Expected behavior
This should either compile just fine, or give an error that shows specifically what type parameter constraint is missing. The hashed names should not be shown. However, in this case, I don't think there's a constraint missing, as the call-site has equal type parameter constraints as the definition.
Actual behavior
It throws both FS0001 and FS0043, with equal texts:
Known workarounds
None, unfortunately (except for dynamic type resolution, but that is not an option here).
Related information
The text was updated successfully, but these errors were encountered: