Bug in D type inferencing

[Hiemlick Hiemlicker via Digitalmars-d]

On Saturday, 2 July 2016 at 08:02:30 UTC, John Colvin wrote:
> On Saturday, 2 July 2016 at 01:20:35 UTC, Hiemlick Hiemlicker 
> wrote:
>> public struct Foo
>> {
>> 	public void Create(T)(uint delegate(T) c, T param)
>> 	{	
>> 	}
>> }
>>
>> Foo f;
>>
>> f.Create((x) { }, "asdf");
>>
>> cannot deduce arguments compiler error.
>>
>> Surely D can figure out that T is a string?
>>
>> If one simply changes this to
>>
>> public struct Foo(T)
>> {
>> 	public void Create(uint delegate(T) c, T param)
>> 	{	
>> 	}
>> }
>>
>> and
>>
>> Foo!string f;
>>
>> everything works.
>>
>> The second parameter is a string so why not infer that T is a 
>> string?
>>
>> Also, if one does
>>
>> f.Create((string x) { }, "asdf");
>>
>> Then it works. Seems like a blatant limitation in D's type 
>> inferencing system.
>
> Those lambdas don't return uint, they return void, so they 
> could never match anyway.
>
> Here's a simple example showing the problem I think you are 
> getting at:
>
> void create(T)(void delegate(T) c, T param) {}
>
> void main()
> {
> //  create((x){}, "fdsa"); // can't deduce
>     create!string((x){},"fdsa"); // OK
>     create((string x){},"fdsa"); // OK
> }
>
> I don't know how difficult it would be to make this work, but 
> you could definitely file an enhancement request for it at 
> issues.dlang.org

Well, I guess I should have put a return in the code on the mock 
up so it wouldn't be taken literal.

The point is, the second argument is definitely a string, is it 
not? So the compiler should be able to deduce that T is a string, 
should it not? Regardless of what the delegate does.