http://d.puremagic.com/issues/show_bug.cgi?id=7019

           Summary: implicit constructors are inconsistently allowed
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: mrmocool@gmx.de


--- Comment #0 from Trass3r <mrmocool@gmx.de> 2011-11-26 16:09:09 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019



--- Comment #1 from Trass3r <mrmocool@gmx.de> 2011-11-26 16:49:56 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


bioinfornatics <bioinfornatics@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bioinfornatics@gmail.com


--- Comment #2 from bioinfornatics <bioinfornatics@gmail.com> 2011-11-30 15:05:37 PST ---
Yes it was exactly what i looking i.e => http://lists.puremagic.com/pipermail/digitalmars-d-learn/2011-November/028194.html

i vote +1

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siegelords_abode@yahoo.com


--- Comment #3 from timon.gehr@gmx.ch 2011-12-17 13:40:18 PST ---
*** Issue 7126 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019



--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> 2012-01-26 06:24:43 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019



--- Comment #5 from Trass3r <mrmocool@gmx.de> 2012-01-26 19:33:22 CET ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com


--- Comment #6 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-01-26 10:39:05 PST ---
(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)).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


mail.mantis.88@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail.mantis.88@gmail.com


--- Comment #7 from mail.mantis.88@gmail.com 2012-01-26 13:55:55 PST ---
(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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #8 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-10-22 08:05:52 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7019


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #9 from Kenji Hara <k.hara.pg@gmail.com> 2012-10-24 07:18:58 PDT ---
(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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------