digitalmars.D.bugs - [Issue 7019] New: implicit constructors are inconsistently allowed
- d-bugmail puremagic.com (43/43) Nov 26 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (12/12) Nov 26 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (12/12) Nov 30 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (10/10) Dec 17 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (11/13) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (8/8) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (13/15) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (37/41) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (29/29) Oct 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (12/40) Oct 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (11/11) Nov 11 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (10/10) Dec 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (6/6) Dec 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (10/10) Dec 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7019
- d-bugmail puremagic.com (24/24) Jan 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7019
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
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
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=7019 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
http://d.puremagic.com/issues/show_bug.cgi?id=7019
bioinfornatics <bioinfornatics gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bioinfornatics gmail.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=7019
timon.gehr gmx.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |siegelords_abode yahoo.com
*** 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
http://d.puremagic.com/issues/show_bug.cgi?id=7019 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
http://d.puremagic.com/issues/show_bug.cgi?id=7019 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
http://d.puremagic.com/issues/show_bug.cgi?id=7019
Vladimir Panteleev <thecybershadow gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thecybershadow gmail.com
10:39:05 PST ---
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
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
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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7019
Andrei Alexandrescu <andrei metalanguage.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrei metalanguage.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=7019
Kenji Hara <k.hara.pg gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
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
http://d.puremagic.com/issues/show_bug.cgi?id=7019 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 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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7019 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
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
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
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
2013-01-10 11:58:19 MSK ---
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