Named arguments and generic type inference in C# 4.0 -

i had been programming under assumption that, when calling method in c# 4.0, supplying names arguments not affect outcome unless in doing "skipping" 1 or more optional parameters.

so bit surprised discover following behavior:

given method takes func<t>, executes , returns result:

public static t f<t>(func<t> f) {     return f(); } 

and method above method visible:

static void main() {     string s; 

calling f (without named arguments) compiles without issues:

    s = f<string>(() => "hello world"); // explicit type argument <string>     s = f(() => "hello world"); // type inference 

and when using named argument...

    s = f<string>(f: () => "hello world"); 

... above line of code using explicit type argument still compiles without issues. , maybe not surprisingly, if have resharper installed suggest "type argument specification redundant".

however, when removing type argument...

    s = f(f: () => "hello world"); 

the c# compiler report error:

the type arguments method 'program.f(system.func)' cannot inferred usage. try specifying type arguments explicitly.

is there logical explanation interaction between named arguments , type inference?

is behavior documented somewhere in language specification?

i understand not necessary @ me name argument. however, discovered behavior in more complex scenario thought might make sense name arguments in method call internal documentation purposes. not asking how work around issue. trying understand of finer points of language.

to make things more interesting discovered following compiles without issues:

    func<string> func = () => "hello world";     s = f<string>(func);     s = f(func);     s = f<string>(f: func);     s = f(f: func); } 

by way have observed same behavior non-static methods. chose use static methods make example here bit shorter.

inference not work @ many nested levels in compilation. kind of guess based on arguments supplied. feel compiler writers did not consider inferring logic along named parameter. if consider abstract syntax tree, though logic same, both f(()=>"xyz") , f(f:()=>"xyz") different abstract syntax trees compiler's perspective.

i feel it's rule missed compiler designer compiler program huge set of rules. 1 rule matches first case no rule matches second one. may conceptually right compiler program , rules human coded.

ok, guess others have determined, bug , should reported microsoft !!