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
instantiation constraints #618
Comments
Note that this is problematic for inference, so unless |
@RossTate Yes, I'm inclined to think you might be right there. It makes type arg inference more fragile. It might also interact badly with the optimization proposed in #485, for the same reason. Now, of course, I suppose we could force you to explicitly specify type args where there is an instantiation constraint, to avoid this kind of fragility. But that's no better than just making you pass the
is no better than:
If we can't infer it
The second like this:
So it's possible this feature is not worth having. |
That's my thinking approximately. |
BTW wouldn't the current reified generics + the future meta data api give us the same possibility? |
I'm not sure what you mean. |
@quintesse No because you can't constrain the type argument to be a concrete class with an appropriate parameter list. |
One of the interesting things you can do with a fully-reified type system, that you can't do when type args aren't reified is instantiate a type parameter. For example:
Surprisingly, to me at least, we havn't yet run into cases where we needed this. I say "surprisingly", because I recollect having wanted to do it in Java. Perhaps this was something very specific to do with other limitations imposed by Java, or perhaps we simply haven't run into the interesting cases yet because we've been building libraries instead of frameworks. Well, anyway we need to think about whether this is truly a useful feature. For now it has been removed from the language spec because it won't make it into 1.0.
The text was updated successfully, but these errors were encountered: