Is partial deduction of generic parameters possible

  • Thread starter Thread starter Vin
  • Start date Start date
V

Vin

Hi,

I just wanted to check if I am missing something or if what I am
looking for isn't possible.

I have a function with 2 generic parameter types, one of these occurs
in the argument list the other doesn't.

So the function is like this:
void CreateEntities<T, IT>(IList<IT> entities){}


I'd like to be able to call it as follows:
IList<IMyType> entities = new List<IMyType>();
CreateEntities<MyType>(entities);

So 'IT' would be deduced as 'IMyType' and 'T' is explicitly set to
'MyType'.

The reasoning behind this is that in the function I will do the
following
entities.Add(new T());


I haven't been able to get this syntax to work.

I have to have:
CreateEntities<MyType, IMyType>(entities);


If I change the function to take an extra useless parameter of type
'MyType' it'll deduce the arguments.
So this will work:
void CreateEntities<T, IT>(IList<IT> entities, T t){}
CreateEntities(entities, new MyType());
but clearly that isn't a useful option.


So is it possible for the compiler to deduce one parameter type or is
it all or none?

Thanks, Vin
 
A shame really... it would be nice (especially when working with
anonymous types) to be able to mix'n'match - perhaps something like:

SomeFunc<?,int>(...)

(where ? means "infer")

I can't think of the examples right now, but I know I've had to refactor
things a few times to get around this... mainly where there isn't any
additional argument relating to a specific argument, or where the
compiler can't fully do the job by itself. Of course, if you have an
anonymous type it becomes very hard to help it!

(we all have our C# wishlists, this is on mine...)

Marc
 
A shame really... it would be nice (especially when working with
anonymous types) to be able to mix'n'match - perhaps something like:

SomeFunc<?,int>(...)

(where ? means "infer")

I can't think of the examples right now, but I know I've had to refactor
things a few times to get around this... mainly where there isn't any
additional argument relating to a specific argument, or where the
compiler can't fully do the job by itself. Of course, if you have an
anonymous type it becomes very hard to help it!

(we all have our C# wishlists, this is on mine...)
Click to expand...

It's been mentioned by other people, too:

http://www.interact-sw.co.uk/iangblog/2008/03/17/lambda-inference

In particular, Ian mentions "in C# team member blogs" which sounds
positive.
Not that I'd like to guess whether it'll be in C# 4 or not...

Jon
 
It's been mentioned by other people, too

Good link, cheers. I like the terminology: "mumble types" ;-p

Marc
 
It's been mentioned by other people, too:

http://www.interact-sw.co.uk/iangblog/2008/03/17/lambda-inference

In particular, Ian mentions "in C# team member blogs" which sounds
positive.
Not that I'd like to guess whether it'll be in C# 4 or not...

Jon
Click to expand...

Hi,

Maybe I am missing something but why would you need the extra syntax?

I'd have thought anything not available from arguments would have to
be specified and anything available wouldn't so the current syntax
would work fine.

void Fn<T1, T2, T3>(T2 t2, T3 t3) {}
would have to be called as
Fn<int>(0, 8);

This does put the restriction that explicit types would have to come
first but the call is cleaner than having to call
Fn<int, ?, ?>(0, 8);

I know this is all speculation at this stage but is there an advantage
to the mumble syntax?

Vin
 
Maybe I am missing something but why would you need the extra syntax?

I'd have thought anything not available from arguments would have to
be specified and anything available wouldn't so the current syntax
would work fine.
Click to expand...

I suspect you'd find it would work fine in some simple cases but not
other more complicated ones. For instance:
void Fn<T1, T2, T3>(T2 t2, T3 t3) {}
would have to be called as
Fn<int>(0, 8);
Click to expand...

And what about when I want to pass null as the second argument? It
would be nice to be able to specify the type for that without casting
the null.

There are various other times where you want to explicitly state the
area of ambiguity.
This does put the restriction that explicit types would have to come
first but the call is cleaner than having to call
Fn<int, ?, ?>(0, 8);
Click to expand...

That's true when it's blindingly obvious which types you want to be
inferred. Other times it may not be so obvious, and that's where
mumble typing helps.

Jon
 
Back
Top