Is partial deduction of generic parameters possible

[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<ITentities){}
I'd like to be able to call it as follows:
IList<IMyTypeentities = 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<ITentities, 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

[Jon Skeet [C# MVP]]

On May 14, 3:40 pm, Vin <[e-mail]:

<snip>

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

All or none, I'm afraid.

Jon

[Vin]

On May 14, 3:44*pm, "Jon Skeet [C# MVP]" <[e-mail]:

All or none, I'm afraid.

Thought it might be :o(

Thanks, Vin

[Marc Gravell]

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

[Jon Skeet [C# MVP]]

On May 16, 3:48*pm, Marc Gravell <[e-mail]:

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...)

It's been mentioned by other people, too:

http://www.interact-sw.co.uk/iangblo...mbda-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

[Marc Gravell]

It's been mentioned by other people, too

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

Marc

[Vin]

On May 16, 4:25*pm, "Jon Skeet [C# MVP]" <[e-mail]:

On May 16, 3:48*pm, Marc Gravell <[e-mail]:

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...)

It's been mentioned by other people, too:

http://www.interact-sw.co.uk/iangblo...mbda-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

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

[Jon Skeet [C# MVP]]

On May 21, 11:11 am, Vin <[e-mail]:

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.

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);

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);

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

[Marc Gravell]

void Fn<T1, T2, T3>(T2 t2, T3 t3) {}

would have to be called as
Fn<int>(0, 8);

And what if we also have a Fn<T>(...)?

Marc

[Jon Skeet [C# MVP]]

On May 21, 1:16 pm, Marc Gravell <[e-mail]:

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

And what if we also have a Fn<T>(...)?

That's a much better answer than mine :)

Jon

[Vin]

On May 21, 1:16*pm, Marc Gravell <[e-mail]:

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

And what if we also have a Fn<T>(...)?

Marc

Fair enough!

Thanks, Vin