Skip to content
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

Open
gavinking opened this issue Mar 2, 2013 · 6 comments
Open

instantiation constraints #618

gavinking opened this issue Mar 2, 2013 · 6 comments

Comments

@gavinking
Copy link
Member

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:

Holder<T> create<T>(String name) given T(String name) => Holder(T(name));

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.

@RossTate
Copy link
Member

RossTate commented Mar 2, 2013

Note that this is problematic for inference, so unless T is determined uniquely be the arguments you should always specify T explicitly. The bigger problem I see is that it's an extremely inflexible constraint, arbitrary along the same lines as structural typing. For design reasons, people should just pass a function here; just make it easy to pass a constructor.

@gavinking
Copy link
Member Author

@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 Class object or a function. What I mean is:

T foo<T>() given T() => T();

is no better than:

T foo<T>(T new()) => new();

If we can't infer it T in the first case. The first one gets called like this:

Foo f = foo<Foo>();

The second like this:

Foo f = foo(Foo);

So it's possible this feature is not worth having.

@RossTate
Copy link
Member

RossTate commented Mar 2, 2013

That's my thinking approximately.

@quintesse
Copy link
Member

BTW wouldn't the current reified generics + the future meta data api give us the same possibility?

@RossTate
Copy link
Member

RossTate commented Mar 3, 2013

I'm not sure what you mean.

@gavinking
Copy link
Member Author

@quintesse No because you can't constrain the type argument to be a concrete class with an appropriate parameter list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants