So, I have this code (also on http://dpaste.dzfl.pl/3f767b17e83c)
This Vector(T) struct is taken from gfm.math.vector.

struct Vector(T) {
	T x, y, z;
	this(X : T, Y : T, Z : T)(X x_, Y y_, Z z_)
	{
		x = x_; y = y_; z = z_;	
	}
}

void main()
{
	Vector!ubyte test = Vector!ubyte(1, 1, 1);	
}

It fails to compile because "template f508.Vector!ubyte.Vector.__ctor cannot deduce function from argument types !()(int, int, int)".
Note that if one just defines a constructor as this(T x_, T y_, T z_) everything works.

My question is: should this code compile? I understand that the literal "1" is "int" therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly.

francesco cattoglio:

> should this code compile? I understand that the literal "1" is "int" therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly.

To keep both the compiler and programmers sane, D templates don't perform implicit type conversions. This sometimes is not handy, but on the whole saves from a large number of troubles.

So you can write (D V.2.066):

Vector!ubyte(ubyte(1), ubyte(1), ubyte(1));

Or you can create a little helper function that makes that code more DRY.

Bye,
bearophile

On Thursday, 24 July 2014 at 09:38:14 UTC, bearophile wrote:
> francesco cattoglio:
>
>> should this code compile? I understand that the literal "1" is "int" therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly.
>
> To keep both the compiler and programmers sane, D templates don't perform implicit type conversions. This sometimes is not handy, but on the whole saves from a large number of troubles.
>
> So you can write (D V.2.066):
>
> Vector!ubyte(ubyte(1), ubyte(1), ubyte(1));
>
> Or you can create a little helper function that makes that code more DRY.
>
> Bye,
> bearophile

I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.

> I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.

Why not use `1u`?

On Wed, Jul 30, 2014 at 11:46 AM, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
>> I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.
>
> Why not use `1u`?

Ow! Ignore that. 1u is an uint, not an ubyte.