Re: 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.

Re: Bug in D type inferencing

[John Colvin via Digitalmars-d]

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

Re: Bug in D type inferencing

[Patrick Schluter via Digitalmars-d]

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


I'm a D noob so take it with a very big grain of salt, but I 
think that expression is wrong already on the level of the 
syntax. In your expression x doesn't have any type, neither 
explicit nor deduced. I suppose that something like that could 
work:


f.Create((auto x) { }, "asdf");  // verbose syntax



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


Here x has a type and the definition is syntactically correct.



Then it works. Seems like a blatant limitation in D's type 
inferencing system.