[Issue 7019] implicit constructors are inconsistently allowed
https://issues.dlang.org/show_bug.cgi?id=7019
--- Comment #16 from Denis Shelomovskij verylonglogin@gmail.com ---
(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?
--
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #13 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #12 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #11 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #10 from github-bugzi...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||pull
--- Comment #9 from Kenji Hara k.hara...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #4 from Kenji Hara k.hara...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #5 from Trass3r mrmoc...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #6 from Vladimir Panteleev thecybersha...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019
mail.mantis...@gmail.com changed:
What|Removed |Added
CC||mail.mantis...@gmail.com
--- Comment #7 from mail.mantis...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 timon.g...@gmx.ch changed: What|Removed |Added CC||siegelords_ab...@yahoo.com --- Comment #3 from timon.g...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 bioinfornatics bioinfornat...@gmail.com changed: What|Removed |Added CC||bioinfornat...@gmail.com --- Comment #2 from bioinfornatics bioinfornat...@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: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #1 from Trass3r mrmoc...@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: ---
