The following code prints:

/home/c494/c719.d(27): Error: (Vec2!(float) __ctmp1173 = _D4c71911__T4Vec2TfZ4Vec26__initZ;
, __ctmp1173).this(4F, 2F) is not an lvalue

[code]
import std.stdio;

struct Vec2(T) {
public:
	T x;
	T y;
	
	this(T x, T y) {
	
	}
}

alias Vec2f = Vec2!(float);

class Foo {
public:
	static Foo make(float i, ref const Vec2f a) {
		return new Foo();
	}
	
	static Foo make(float i, const Vec2f a) {
		return Foo.make(i, a);
	}
}

void main() {
	Foo f = Foo.make(42, Vec2f(4, 2));
}
[/code]

If I change i from float to int it works. Also if I write 42f instead of 42. That is strange. Could someone explain me that?

Same with this code: http://dpaste.1azy.net/2c98fe95
But there I found no workaround.

Looks like a bug in function overload selection.

On Sunday, 27 January 2013 at 11:42:29 UTC, Dicebot wrote:
> Looks like a bug in function overload selection.

I hope not!
That would be really bad. That is part of my solution as long as auto ref isn't there. :D

> Same with this code: http://dpaste.1azy.net/2c98fe95
> But there I found no workaround.

This works: new C(cast(A) new B(), FloatRect(0, 1, 2, 3));
But that is ugly. o.O

I think you are right and it is a bug in function overload selection. :(

Ok, I will open a bug report for this.

On Sunday, January 27, 2013 12:42:28 Dicebot wrote:
> Looks like a bug in function overload selection.

Definitely.

- Jonathan M Davis

On Sunday, 27 January 2013 at 23:05:16 UTC, Jonathan M Davis wrote:
> On Sunday, January 27, 2013 12:42:28 Dicebot wrote:
>> Looks like a bug in function overload selection.
>
> Definitely.
>
> - Jonathan M Davis

And that prevents a workaround for the missing auto ref. :o)
It seems dmd 2.060 is far more useable than 2.061 (for users which use structs, of course).
I will switch back.

> And that prevents a workaround for the missing auto ref. :o)
> It seems dmd 2.060 is far more useable than 2.061 (for users which use structs, of course).
> I will switch back.

I'm still interested in this problem. But how can I identify the specific compiler code where this error comes from?
I know where the error is thrown and where the matching fail comes from (expression.c) but not _why_ the matching fails happen.
Could you give me a quick explanation?

On Monday, January 28, 2013 11:16:26 Namespace wrote:
> > And that prevents a workaround for the missing auto ref. :o)
> > It seems dmd 2.060 is far more useable than 2.061 (for users
> > which use structs, of course).
> > I will switch back.
> 
> I'm still interested in this problem. But how can I identify the
> specific compiler code where this error comes from?
> I know where the error is thrown and where the matching fail
> comes from (expression.c) but not _why_ the matching fails happen.
> Could you give me a quick explanation?

I have no idea why it's failing. That would require debugging the compiler, and the only part of the compiler that I know much about is the lexer.

- Jonathan M Davis

It's fixed already. But I searched at the wrong place. The compiler is too huge for me. o.O