-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
in some cases we could get more from type declarations #271
Comments
I've often thought about having the ability to declare the type of a function as a whole. Something along the lines of
Not sure about the syntax, of course, but the idea is that this is a generic way of saying that the convert function always takes two or more arguments, the first of which must be a Type value, the rest of which may be anything, and that it always returns a value the type specified by its first argument. Other examples would be much simpler than this. This would also potentially serve to declare a generic function before declaring any particular methods of it, which would occasionally be handy. |
Do we have plans to do anything here? |
The latter suggestion (mine) is already a separate issue. I'm not sure about convert, although I'd be willing to require that convert always return an object of the demanded type. |
It seems reasonable to me that convert should return an object of the demanded type. If it doesn't, we should get a nice error though. |
I'm not sure how we would go about inserting a type check. If there was a type check, then the inference system would automatically know the type, but the only way I can think to make that work is to have a |
For declaring function types, we need 2 things: declaring the return type of one method, and of the whole generic function. |
Ah, yes. If we could write something like this: convert::(T::Type,x)-->T then we could express this for the entire convert function. Would be a generally useful feature, but seems like a lot of work to get right. Also reintroduces function types, which is a questionable complication at this point. |
can we close this in favor of the more descriptive issue #1090? |
No, these are different issues. |
It would also be great to have this for |
Currently type declarations are implemented with
convert
. The problem is, in a case like thisthere are so many matching convert methods that we can't infer the result type. We could either cheat and assume convert always returns something of the right type or, probably better, add a layer of
typeassert
to make sure convert returns the right thing in this case.The text was updated successfully, but these errors were encountered: