Bug 7019 – implicit constructors are inconsistently allowed

Yes, I'm aware that alias this makes it possible to allow implicit conversions, but it can't solve everything, esp. if you need to modify the value before you 'save' it: import std.stdio; struct A { int store; this(int a) { store = a << 3; //... } } void main() { A a = 5; // this compiles fine writeln(a.store); // prints 40 // but it doesn't work on function calls foo(5); // Error: cannot implicitly convert expression (5) of type int to A } // nor does it work at global scope or on struct/class fields A a = 5; // Error: cannot implicitly convert expression (5) of type int to A void foo(A a) {} This is horribly and incomprehensibly inconsistent. btw, if somebody is able to come up with a serious reason why these shouldn't be allowed in general, I suggest to introduce @implicit.

Especially the function argument one bugs me. I have a vector struct templated on the number type. It is instantiated with a handful of basic types like float, int etc. and a custom fixed-point number struct. This single 'outlier' requires me to introduce yet another template that handles the conversion from a number literal to fixed-point or basic type and clutters the code.

Yes it was exactly what i looking i.e => http://lists.puremagic.com/pipermail/digitalmars-d-learn/2011-November/028194.html i vote +1

*** Issue 7126 has been marked as a duplicate of this issue. ***

Is this a dup of 4875? Recently Walter commented in that issue, and marked it WONTFIX. He said: > Allowing such implicit conversions works in C++, but is considered a defect by > experienced C++ professionals. We won't repeat the mistake. But he doesn't mention about the inconsistency. We need more discussion. Personally implicit constructor call on initializer is useful, e.g. BigInt. It is more better that can specify implicit or explicit.

I vote for doing the opposite of C++ and introducing a @implicit tag for constructors that are to be used in the fashion I depicted. We really need an easy way to finely control implicit conversions.

(In reply to comment #5) > I vote for doing the opposite of C++ and introducing a @implicit tag for > constructors that are to be used in the fashion I depicted. If we had opImplicitCast (for implicit casting of "this" to another type), this could have been named opImplicitCast_r (for implicit casting of another type to typeof(this)).

(In reply to comment #0) > Yes, I'm aware that alias this makes it possible to allow implicit conversions, > but it can't solve everything, esp. if you need to modify the value before you > 'save' it: > ... Why not aliasing this to set/get methods, e.g: struct Foo(T) { alias prop this; this( in T value ) { m_Prop = value; } @property: T prop() const { return m_Prop; } ref auto prop( in T value ) { return(m_Prop = value, this); } private: T m_Prop; } void bar(T)( in Foo!T foo ) { writeln( cast(T)foo ); } int main() { Foo!int foo = 42; bar( foo ); foo = 10; bar( foo ); return 0; } Are there any problems I'm not aware of?

Consider (assuming A has an int-accepting ctor): A object = A(1); // or auto object = A(1); In here the name of the type being constructed appears in clear, so there's no chance for a potential confusion. The code currently works, as it should. Consider: A object = 1; Again the type being constructed appears in clear. The code works in a function but not at top level. It is a bug that it doesn't work at top level, because the equivalent construct A object = A(1) does. Now consider: void fun(A) { ... } fun(1); In here there's no explicit mention of A in the call, which makes this case qualitatively different from the ones above. Currently the compiler rejects the code and I think it does very well so. Implicit conversions on function calls is unrecommended in the presence of function overloading, and essentially C++ made a mistake about it that it has later partially fixed with the "explicit" keyword. We won't repeat that mistake.

(In reply to comment #8) > Consider (assuming A has an int-accepting ctor): > > A object = A(1); > // or > auto object = A(1); > > In here the name of the type being constructed appears in clear, so there's no > chance for a potential confusion. The code currently works, as it should. > > Consider: > > A object = 1; > > Again the type being constructed appears in clear. The code works in a function > but not at top level. It is a bug that it doesn't work at top level, because > the equivalent construct A object = A(1) does. > > Now consider: > > void fun(A) { ... } > fun(1); > > In here there's no explicit mention of A in the call, which makes this case > qualitatively different from the ones above. Currently the compiler rejects the > code and I think it does very well so. Implicit conversions on function calls > is unrecommended in the presence of function overloading, and essentially C++ > made a mistake about it that it has later partially fixed with the "explicit" > keyword. We won't repeat that mistake. Implemented. https://github.com/D-Programming-Language/dmd/pull/1213

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f51a4268bcf42e14ef40bdc0137399cddc965f03 fix Issue 7019 - implicit constructors are inconsistently allowed https://github.com/D-Programming-Language/dmd/commit/2daf24fd4a036331d3428f9381c65a9be3b12319 Merge pull request #1213 from 9rnsr/fix7019 Issue 7019 - implicit constructors are inconsistently allowed

*** Issue 7673 has been marked as a duplicate of this issue. ***

*** Issue 7152 has been marked as a duplicate of this issue. ***

*** Issue 9217 has been marked as a duplicate of this issue. ***

A testcase from dmd pull #1213 discussion https://github.com/D-Programming-Language/dmd/pull/1213#issuecomment-10402603 --- struct S { this(int) { } } struct S2 { S s; } void f(S s) { } // explicit, there is S here: S s = 5; // ok // implicit, there is no S here: static assert(!__traits(compiles, f(5))); // ok static assert(!__traits(compiles, { S2 s2 = 5; })); // ok static assert(!__traits(compiles, { S2 s2 = S2(5); })); // ok static assert(!__traits(compiles, { S2 s2 = { 5 }; })); // fails static assert(!__traits(compiles, { S2 s2 = { s: 5 }; })); // fails ---

Remained issue will be fixed by issue 8864. struct S { this(int) { } } S[2] a = [1,2]; // Converted to: [S(1), S(2)] (In reply to Denis Shelomovskij from comment #14) > static assert(!__traits(compiles, { S2 s2 = { 5 }; })); // fails > static assert(!__traits(compiles, { S2 s2 = { s: 5 }; })); // fails These are expected behavior. The target type of the argument '5' can be determined to S, so implicit constructor call is handled.

(In reply to Kenji Hara from comment #15) > (In reply to Denis Shelomovskij from comment #14) > > static assert(!__traits(compiles, { S2 s2 = { 5 }; })); // fails > > static assert(!__traits(compiles, { S2 s2 = { s: 5 }; })); // fails > > These are expected behavior. > The target type of the argument '5' can be determined to S, so implicit > constructor call is handled. How does `S2 s2 = { 5 }` differ from `f(5)` or `S2 s2 = S2(5)`? IMO the only clean rule is: "Implicit conversion exists iff target type is explicitly stated." What is wrong with this rule? What rules and why are preferred?