www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7019] New: implicit constructors are inconsistently allowed

reply d-bugmail puremagic.com writes:
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: -------
Nov 26 2011
next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 30 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 17 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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:
 ...

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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 24 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7019



--- Comment #10 from github-bugzilla puremagic.com 2012-11-11 00:01:14 PST ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 11 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7019


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com


--- Comment #11 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2012-12-02
11:17:18 PST ---
*** Issue 7673 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: -------
Dec 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7019



--- Comment #12 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2012-12-23
06:17:09 PST ---
*** Issue 7152 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: -------
Dec 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7019


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #13 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2012-12-27
09:04:48 PST ---
*** Issue 9217 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: -------
Dec 27 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7019


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com


--- Comment #14 from Denis Shelomovskij <verylonglogin.reg gmail.com>
2013-01-10 11:58:19 MSK ---
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
---

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