[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Ali Cehreli acehr...@yahoo.com changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #13 from Ali Cehreli acehr...@yahoo.com --- If the implicitly-converted value is an rvalue (as it is), where is it stored to take the reference of? Since it is not possible to take the address of an rvalue simply because it may be sitting in a register, I can't see how this fix can be reverted without special-casing the compiler. What kinds of rvalues should we start taking references of? It is unfortunate that this breaks compilation of wrong code but I think the extent of code change should be minimal. Anyway, 2.066.1 is still available. :) Ali --
[Issue 14267] [REG2.067beta2] ICE when determining if a function can be inlined
https://issues.dlang.org/show_bug.cgi?id=14267 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c29d893a456a9dfee532c2b0a5f6615b3dbc080f Merge pull request #4471 from 9rnsr/fix14267 [REG2.067beta2] Issue 14267 - ICE when determining if a function can be inlined --
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 --- Comment #9 from Denis Shelomovskij verylonglogin@gmail.com --- (In reply to Kenji Hara from comment #8) (In reply to Martin Nowak from comment #7) So what's the conclusion here? Denis argues that mutable key char[] should be allowed for the AA indexing. But AA key should be const on indexing, and should be immutable on setting. Therefore specifying mutable key char[] is not possible. Everything I want is to clarify AA behviour (emn... no, really I'd like to remove this from a language as a terrible misfeature, but I'm almost alone here so I do not propose it). Regarging to types accepted by AAs I'd like Issue 12491 Issue 12492 to be discussed and resolved some way. (I'm saying if and only if a NewExpression `new char[1]` is directly used, it can be convertible to immutable(char[]) by the uniqueness. But it's different from his intention.) This issue isn't connected with `immutable` at all. As I wrote in description it's just a misleading error mesage. Go to enhancement Issue 12491 for AA and immutability discussion. Therefore this issue should be closed as invalid. I can't believe anyone can accept bahaviour shown in Comment 6. --
[Issue 14270] New: final interface: attribute is ignored
https://issues.dlang.org/show_bug.cgi?id=14270
Issue ID: 14270
Summary: final interface: attribute is ignored
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: rswhi...@gmail.com
This code works:
final interface Foo { }
class Bar : Foo { }
But it shouldn't. It seems that the final attribute is ignored.
So we have two choices:
#1: Disallow the final attribute for interfaces
#2: Recognize it correctly
Since this code works (to emulate C++ namespaces, I think):
---
final abstract class Quatz { }
and this is disallowed:
class Test : Quatz { }
We should go with #2
--
[Issue 14280] New: Links to command line tools have disappeared from navigation
https://issues.dlang.org/show_bug.cgi?id=14280 Issue ID: 14280 Summary: Links to command line tools have disappeared from navigation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com There is no way to navigate to the following pages: dmd-freebsd.html dmd-linux.html dmd-osx.html dmd-windows.html from dlang.org --
[Issue 14277] New: Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 Issue ID: 14277 Summary: Compile-time array casting error - ugly error report Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: czda...@gmail.com Hey, look at this code: http://dpaste.dzfl.pl/ce4c5230ac18 If not working:: static ubyte[] u = new char[]; The error report is kinda ugly, isn't it? --
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/9010ecd4b0942e0eb0c37c073d4d53f1984f7872 Merge pull request #2971 from monarchdodra/14135 Issue 14135 - std.uuid.randomUUID breaks @safety --
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 monarchdo...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 rather than erroring is this function is not checking for errors, it does match levels, which can cause various changes upstream. --
[Issue 14279] [REG:git-head]Failed to make dmd because of idgen : HOST_DC missing
https://issues.dlang.org/show_bug.cgi?id=14279 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4492 --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 deprecation rather than immediately making it an error like we'd normally do with an accepts-invalid bug on the theory that the code actually works in spite of violating the type system, then fine. But I don't think that it's at all a good idea to leave the code as valid long term. This was my point from the very first comment here ;) Yes, this is bad code and disallowing it will make type system more uniform. But it isn't inherently broken and thus deprecation stage is mandatory. I will look into relevant code closer to the weekend if no one else will have done it by that point. --
[Issue 14277] Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 --- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org --- Created attachment 1491 -- https://issues.dlang.org/attachment.cgi?id=1491action=edit trim output of long expressions as far as i know, `Expression::toChars()` is not using in anything vital, only in diagnostic output. so i trimming it's result to arbitrary limit of 200 chars. maybe it's better to fix array literal output, but this is easier, and it will additionaly limit output of other long expressions, which are unreadable anyway if they reaches that size. --
[Issue 14277] Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- p.s. this can ruing long utf-8 literals, though. not that i really care. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 don't know if this makes things clear. What should be wrong code? The situation in the unreleased compiler or the situation in 2.066.1? --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #33 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Andrei Alexandrescu from comment #32) Code that attempts to convert an lvalue of enum type to a ref to its base type is wrong. The compiler shouldn't accept it. Correcting it qualifies as a simple bug fix. OK, so that is what already happened. I don't agree with it, but I don't see that it is worth having a battle over. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 deprecation. Any code that relies on this bug was wrong. I don't know if this makes things clear. What should be wrong code? The situation in the unreleased compiler or the situation in 2.066.1? Code that attempts to convert an lvalue of enum type to a ref to its base type is wrong. The compiler shouldn't accept it. Correcting it qualifies as a simple bug fix. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 {}
void foo(Object o);
void main()
{
C c = new C;
foo(c); // works, and passed by ref!
}
I think clearly there is a similar relationship with enums and their base type.
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
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
}
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 passable as a ref to a base Object. A ref to a
C object *reference* is not passable as a ref to a base Object reference for
correct reasons.
The equivalent to your code for enums would be:
void foo (int *o) {
o = new int;
}
enum E : int;
void main () {
E *c = new E;
auto n = c;
foo(c);
assert(c == n); // assertion passed
}
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
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. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 --- Comment #25 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to Steven Schveighoffer from comment #24) foo(c); // works, and passed by ref! but it's in no way passed by ref! O_O --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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
is a clear violation of the type system.
class C {}
void foo(Object o);
void main()
{
C c = new C;
foo(c); // works, and passed by ref!
}
I think clearly there is a similar relationship with enums and their base
type.
In that case, you're not passing by ref. You're dealing with a reference type -
and a polymorphic one at that. There is nothing polymorphic about enums unless
they happen to have a class type as their base type. And this code does _not_
compile:
class C {}
void foo(ref Object o);
void main()
{
C c = new C;
foo(c);
}
ref and class references are not the same thing at all.
--
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
https://issues.dlang.org/show_bug.cgi?id=7067 --- Comment #23 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- @Martin @Jens: sorry for radio silence on this. It's a busy period, and I recently moved to a new apartment where I still don't have home internet. I don't think that sharing rng state among multiple consumers is a good idea. Of course it looks like you want random numbers and shouldn't care about the order, but often fixed seeds are used to get a reproducible pseudo-random range. When you share such a RNG as in auto rng = Random(fixedSeed); assert(!equal(randomCover(a, rng), randomCover(a, rng))); the sequences depends on the implementation of equal and randomCover. Yes, a case like this obviously creates complications. But I don't think subtleties like this should prevent a user from instantiating one RNG instance and using it with multiple consumers. The default case (where no RNG instance is passed) already employs a common RNG instance between different consumers; I'd rather have consistency of behaviour whether an RNG is explicitly provided or not. Of course, we can advise associating different RNG instances with different consumers (or making sure that a consumer does its work before associating an RNG with a new consumer), but that's different from compelling the user to follow this pattern. Note also that one-RNG-per-consumer really doesn't scale to e.g. a simulation where you are generating thousands or millions of random samples. The risk of the different RNG seeds generating correlated sequences seems greater than the risks associated with using one RNG underlying all sample instances. Also we'd set a bad precedent by making one of std's ranges a ref type. Ref ranges have a lot of subtleties and aren't that well tested with std.algorithm. I agree there are a lot of subtleties, but my feeling is that we need to embrace and explore those in order to identify what the best way forward is for RNGs. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 lvalue). (Steven says it's the latter.) Since this change has broken code, the question to answer is, does this break code that should be broken? Final switch does not show a case of invalid code that is now fixed by this change, and I haven't seen any other challenges of breakage. So if it doesn't break anything worth breaking, why are we doing it? To me, this doesn't break any code that is invalid. Regardless of whether it's philosophically correct or not, avoiding breaking only valid code should take precedence. That is why I said I understand the reason and somewhat agree with the reason, but I still think it should be reverted. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
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 making it an error like we'd normally do with an accepts-invalid bug on the theory that the code actually works in spite of violating the type system, then fine. But I don't think that it's at all a good idea to leave the code as valid long term. --
[Issue 14275] Qualified package protection for aggregate member doesn't work
https://issues.dlang.org/show_bug.cgi?id=14275 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a44e09d3d16b7c23e540bce8be5dffde2dfa17fa Merge pull request #4476 from mihails-strasuns-sociomantic/fix-14275-aggregate-member-protection Fix issue 14275 : qualified package protection for aggregate member doesn't work --
[Issue 13649] uniform01 Assertion failure
https://issues.dlang.org/show_bug.cgi?id=13649 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/c561951994e04293041906ee468b502806680e20 Fix Issue 13649 - uniform01 Assertion failure https://github.com/D-Programming-Language/phobos/commit/2679e447739cb5190b2cd2fd61a36979752478da Merge pull request #2969 from e10s/patch-8 Fix Issue 13649 - uniform01 Assertion failure --
[Issue 6766] Forward reference error for default struct/class arguments
https://issues.dlang.org/show_bug.cgi?id=6766 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- *** Issue 9397 has been marked as a duplicate of this issue. *** --
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #7 from Martin Nowak c...@dawg.eu --- So what's the conclusion here? --
[Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues
https://issues.dlang.org/show_bug.cgi?id=340 Issue 340 depends on issue 9397, which changed state. Issue 9397 Summary: Size error with struct with ctor and self-typed nested enum https://issues.dlang.org/show_bug.cgi?id=9397 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 --- Comment #8 from Kenji Hara k.hara...@gmail.com --- (In reply to Martin Nowak from comment #7) So what's the conclusion here? Denis argues that mutable key char[] should be allowed for the AA indexing. But AA key should be const on indexing, and should be immutable on setting. Therefore specifying mutable key char[] is not possible. (I'm saying if and only if a NewExpression `new char[1]` is directly used, it can be convertible to immutable(char[]) by the uniqueness. But it's different from his intention.) Therefore this issue should be closed as invalid. --
