## digitalmars.D.learn - What's the rationale here? alias this and function arguments

• John Colvin (24/24) Mar 10 2015 struct S
• ketmar (13/36) Mar 10 2015 autoconversion for function arguments can lead to bug-ridden code, and i...
• John Colvin (4/37) Mar 10 2015 Ah yep, overloading, that was it. I have the feeling i've asked
• Baz (12/36) Mar 10 2015 Do you think that the parameter should be automatically created
"John Colvin" <john.loughran.colvin gmail.com> writes:
```struct S
{
int a;
this(T)(T v)
{
this = v;
}
void foo(T)(T v)
{
import std.conv : to;
a = v.to!int;
}
alias foo this;
}

void bar(S s){}

void main()
{
S s0;
s0 = "3"; //OK
S s = "3"; //OK
bar("3"); //Not OK
}

It would seem logical that the last one would work as well.
What's the reasoning behind this?
```
Mar 10 2015
ketmar <ketmar ketmar.no-ip.org> writes:
```On Tue, 10 Mar 2015 10:27:13 +0000, John Colvin wrote:

struct S {
int a;
this(T)(T v)
{
this =3D v;
}
void foo(T)(T v) {
import std.conv : to;
a =3D v.to!int;
}
alias foo this;
}
=20
void bar(S s){}
=20
void main()
{
S s0;
s0 =3D "3"; //OK S s =3D "3"; //OK bar("3"); //Not OK
}
=20
It would seem logical that the last one would work as well.
What's the reasoning behind this?

autoconversion for function arguments can lead to bug-ridden code, and is=20
a perfect way to disaster. besides, it's ambiguous. let's imagine that we=20
have struct `S1`, which can be created from string too, and overload of=20
`bar` as `void bar (S1 s)`. what `bar` compiler should choose for `bar
("3")`?

so compiler doesn't try to guess how to convert your function argument=20
from valid constructor args to structs. this decreases the change to=20
introduce a hard-to-detect bugs with implicit construction, and also=20
in the code, but no `bar` overload that accepts string).

C++ tries to be "smart" here, and fails. D doesn't try to be smart, as=20
it's not a compiler work to guess what you meant.=
```
Mar 10 2015
"John Colvin" <john.loughran.colvin gmail.com> writes:
```On Tuesday, 10 March 2015 at 10:36:21 UTC, ketmar wrote:
On Tue, 10 Mar 2015 10:27:13 +0000, John Colvin wrote:

struct S {
int a;
this(T)(T v)
{
this = v;
}
void foo(T)(T v) {
import std.conv : to;
a = v.to!int;
}
alias foo this;
}

void bar(S s){}

void main()
{
S s0;
s0 = "3"; //OK S s = "3"; //OK bar("3"); //Not OK
}

It would seem logical that the last one would work as well.
What's the reasoning behind this?

autoconversion for function arguments can lead to bug-ridden
code, and is
a perfect way to disaster. besides, it's ambiguous. let's
imagine that we
have struct `S1`, which can be created from string too, and
`bar` as `void bar (S1 s)`. what `bar` compiler should choose
for `bar
("3")`?

this before and someone else explained it to me but I had
forgotten. Cheers
```
Mar 10 2015
"Baz" <bb.temp gmx.com> writes:
```On Tuesday, 10 March 2015 at 10:27:14 UTC, John Colvin wrote:
struct S
{
int a;
this(T)(T v)
{
this = v;
}
void foo(T)(T v)
{
import std.conv : to;
a = v.to!int;
}
alias foo this;
}

void bar(S s){}

void main()
{
S s0;
s0 = "3"; //OK
S s = "3"; //OK
bar("3"); //Not OK
}

It would seem logical that the last one would work as well.
What's the reasoning behind this?

Do you think that the parameter should be automatically created
from the argument ? Is this kind of thing even possible in
another context ?

Your alias looks more like an ```opCall()```. To my eyes the
strange thing is that if you add the following statement at the
end of you sample:
---
s(0);
---

DMD outputs:

```Error: cannot resolve type for s.foo(T)(T v)```
```
Mar 10 2015