-
Notifications
You must be signed in to change notification settings - Fork 2
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
Support return type assertions #8
Comments
Hi there, thanks for writing this package, it is really great! We are currently using it to streamline a bigger project we have, and I think it would be nice to be able to check that an implemented type both takes the right kind of arguments and returns something expected. Do you think you will incorporate return type assertions into this package? |
I still want to support this, yes, but the checking part for this is, in general, a bit tricky. Consider this type for example:
Evidently, this type implements the
The return type is
but then you run into the issue of figuring out that relationship in the first place; really, what the interface requires is not that To be clear, I still want to have the implicit return type assertion work - it's just a bit more tricky and definitely requires "breaking apart" types given when checking an interface into constituent parts, potentially picking |
That makes sense. I appreciate the detailed answer, it shows you are thinking it through carefully :) Still, even the ability to specify the interface like your package already allows is really very cool, and definitely a step in the right direction for the Julia ecosystem! |
@timholy brought up a good point in JuliaLang/julia#49973 (comment), namely that sometimes return type assertions are useful. This would (optionally) be checked as well when checking for interface conformity. The syntax to use this would be (in the example of
AbstractArray
s):where the
T
ingetindex
would be forced to match. This could potentially be implemented withBase.return_type
. Though I do admit not liking relying on inference, there's no way around it in this case.The text was updated successfully, but these errors were encountered: