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.
