https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #35 from Dicebot pub...@dicebot.lv ---
After small e-mail conversation with Walter we came to compromise that this
specific issue will remain closed as deprecation can possibly be more
problematic than the fix but this won't be considered
https://issues.dlang.org/show_bug.cgi?id=14269
Ali Cehreli acehr...@yahoo.com changed:
What|Removed |Added
CC||acehr...@yahoo.com
---
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #34 from Walter Bright bugzi...@digitalmars.com ---
Here's the change that did it:
https://github.com/D-Programming-Language/dmd/pull/4177/files
Essentially, it's the removal of the toBasetype() call.
The problem with deprecating
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #23 from Dicebot pub...@dicebot.lv ---
(In reply to Jonathan M Davis from comment #22)
I think that allowing an implicit conversion to be used with a ref parameter
is a clear violation of the type system. If we want to fix it via
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #31 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Andrei Alexandrescu from comment #30)
This is a simple accepts-wrong-code bug that needs to be fixed with no
deprecation. Any code that relies on this bug was wrong.
I
https://issues.dlang.org/show_bug.cgi?id=14269
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #32 from Andrei Alexandrescu and...@erdani.com ---
(In reply to Steven Schveighoffer from comment #31)
(In reply to Andrei Alexandrescu from comment #30)
This is a simple accepts-wrong-code bug that needs to be fixed with no
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #24 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Jonathan M Davis from comment #22)
I think that allowing an implicit conversion to be used with a ref parameter
is a clear violation of the type system.
class C {}
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #26 from Ketmar Dark ket...@ketmar.no-ip.org ---
class C {}
void foo (Object o) {
o = new Object();
}
void main () {
C c = new C;
auto n = c;
foo(c);
assert(c == n); // assertion passed
}
--
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #28 from Steven Schveighoffer schvei...@yahoo.com ---
The Object contents are passed by ref, just like the enum contents are.
The difference is that the ref is implicit for the object. In other words, a
ref to a C object is implicitly
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #27 from Ketmar Dark ket...@ketmar.no-ip.org ---
ah, sorry, replace that assert with `assert(c is n);` for clarity.
--
https://issues.dlang.org/show_bug.cgi?id=14269
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #30 from Andrei Alexandrescu and...@erdani.com ---
This is a simple accepts-wrong-code bug that needs to be fixed with no
deprecation. Any code that relies on this bug was wrong.
--
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #29 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
(In reply to Steven Schveighoffer from comment #24)
(In reply to Jonathan M Davis from comment #22)
I think that allowing an implicit conversion to be used with a ref parameter
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #21 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Ali Cehreli from comment #18)
I think this boils down to whether an enum's conversion to its base type is
an implicit cast (an rvalue), versus the enum itself (an
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #22 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
I think that allowing an implicit conversion to be used with a ref parameter is
a clear violation of the type system. If we want to fix it via deprecation
rather than immediately
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #20 from Kenji Hara k.hara...@gmail.com ---
(In reply to Dicebot from comment #19)
(In reply to Ali Cehreli from comment #18)
Also, does anyone know what bug fix this was originally about? Perhaps that
bug was invalid?
Ali
https://issues.dlang.org/show_bug.cgi?id=14269
Ali Cehreli acehr...@yahoo.com changed:
What|Removed |Added
CC||and...@erdani.com,
https://issues.dlang.org/show_bug.cgi?id=14269
Dicebot pub...@dicebot.lv changed:
What|Removed |Added
CC||pub...@dicebot.lv
--- Comment #3
https://issues.dlang.org/show_bug.cgi?id=14269
Jonathan M Davis issues.dl...@jmdavisprog.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #5 from Dicebot pub...@dicebot.lv ---
It's quite normal
It is common, not normal. And this attitude needs to change if D wants to be
considered stable for production usage for wider audience. Fortunately, so far
seem that Martin shares
https://issues.dlang.org/show_bug.cgi?id=14269
ncras...@gmail.com changed:
What|Removed |Added
CC||ncras...@gmail.com
--
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #7 from Dicebot pub...@dicebot.lv ---
For the stability, we have to defer to fix bug by adding deprecation stage
Yes, unless it compromises program correctness (memory corruption, wrong
codegen etc). It is a normal practice in majority
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #6 from Kenji Hara k.hara...@gmail.com ---
(In reply to Dicebot from comment #5)
And this attitude needs to change if D wants to be
considered stable for production usage for wider audience.
For the stability, we have to defer to fix
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #8 from Kenji Hara k.hara...@gmail.com ---
(In reply to Dicebot from comment #7)
unless it compromises program correctness (memory corruption, wrong
codegen etc).
In 2.066 and earlier, the program correctness had been compromised and
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #12 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Jonathan M Davis from comment #10)
Personally, I think that all operations that the compiler can't guarantee
will result in a valid enum value for an enum type should
https://issues.dlang.org/show_bug.cgi?id=14269
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #10 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
Personally, I think that all operations that the compiler can't guarantee will
result in a valid enum value for an enum type should result in the base type of
the enum rather than
https://issues.dlang.org/show_bug.cgi?id=14269
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #15 from monkeywork...@hotmail.com ---
(In reply to Dicebot from comment #3)
It shouldn't compile but, same as with other such changes, it needs
deprecation stage.
That would imply that deprecations are ever done in D ;-) How long has
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #14 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Ali Cehreli from comment #13)
If the implicitly-converted value is an rvalue (as it is), where is it
stored to take the reference of?
No, an enum is a derivative. It's
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #17 from Dicebot pub...@dicebot.lv ---
Also, please, can we discuss the final switch / enum operation issue somewhere
else? It is unrelated and only makes more difficult to follow relevant
discussion.
--
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #16 from Dicebot pub...@dicebot.lv ---
(In reply to Kenji Hara from comment #8)
(In reply to Dicebot from comment #7)
unless it compromises program correctness (memory corruption, wrong
codegen etc).
In 2.066 and earlier, the
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #18 from Ali Cehreli acehr...@yahoo.com ---
I think this boils down to whether an enum's conversion to its base type is an
implicit cast (an rvalue), versus the enum itself (an lvalue). (Steven says
it's the latter.)
Also, does anyone
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #19 from Dicebot pub...@dicebot.lv ---
(In reply to Ali Cehreli from comment #18)
I think this boils down to whether an enum's conversion to its base type is
an implicit cast (an rvalue), versus the enum itself (an lvalue). (Steven
https://issues.dlang.org/show_bug.cgi?id=14269
monkeywork...@hotmail.com changed:
What|Removed |Added
Summary|Enum is not implicitly |Enum is not implicitly
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #2 from monkeywork...@hotmail.com ---
According to Jonathan Davis it should not compile, as there are no implicit
conversions with ref. It *is* a regression in behaviour, though.
--
37 matches
Mail list logo
