[Issue 2631] alias symbol this;
http://d.puremagic.com/issues/show_bug.cgi?id=2631 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #9 from yebblies yebbl...@gmail.com 2011-06-15 23:13:29 PDT --- (In reply to comment #8) This became a cool feature. And then became a closed enhancement request -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5061] std.traits.arrayTarget
http://d.puremagic.com/issues/show_bug.cgi?id=5061 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-15 23:16:49 PDT --- Is this covered by ElementType/EncodingType? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5817] rt.lifetime: no generic overflow catching code for _d_newarray(i)T
http://d.puremagic.com/issues/show_bug.cgi?id=5817 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Iain Buclaw ibuc...@ubuntu.com 2011-06-15 23:17:46 PDT --- https://github.com/D-Programming-Language/druntime/commit/0a78837db20a68cbeac7389777e834b8b3910be4 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6163] std.bigint: x.opBinary(y) is not an lvalue
http://d.puremagic.com/issues/show_bug.cgi?id=6163 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-15 23:30:06 PDT --- *** This issue has been marked as a duplicate of issue 3659 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5471] Delegates with qualified value params can't be implicitly cast
http://d.puremagic.com/issues/show_bug.cgi?id=5471 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-15 23:36:12 PDT --- This is delegate contravariance, and is not going to happen. *** This issue has been marked as a duplicate of issue 3075 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3075] void delegate(const(void)[]) should be implicitly convertable to void delegate(void[])
http://d.puremagic.com/issues/show_bug.cgi?id=3075 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||eatingstap...@gmail.com --- Comment #22 from yebblies yebbl...@gmail.com 2011-06-15 23:36:12 PDT --- *** Issue 5471 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 5480] TDPL exception chaining not implemented (except on Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=5480 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-15 23:39:57 PDT --- As of dmd2.053, this has been implemented for posix -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5472] Overriding virtual function with qualified parameters causes error
http://d.puremagic.com/issues/show_bug.cgi?id=5472 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||WONTFIX Severity|normal |enhancement --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-15 23:37:29 PDT --- This is contravariance for parameters, and is not going to happen. See Walter's comments in issue 3075. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4174] Template interface functions not allowed, making operator overloads difficult
http://d.puremagic.com/issues/show_bug.cgi?id=4174 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid CC||yebbl...@gmail.com --- Comment #4 from yebblies yebbl...@gmail.com 2011-06-16 00:02:54 PDT --- https://github.com/D-Programming-Language/dmd/pull/131 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4818] Taking address of shared member function - unshared delegate
http://d.puremagic.com/issues/show_bug.cgi?id=4818 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-16 00:13:35 PDT --- With dmd 2.053 this prints: testx.d(9): Error: cannot implicitly convert expression (foo.bar) of type void delegate() shared to shared(void delegate()) Which shows the delegate is being typed correctly. shared(void delegate()) is not the same type as shared(void delegate() shared) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5818] 64bit ASM can't have 32-bit stack operands
http://d.puremagic.com/issues/show_bug.cgi?id=5818 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED --- Comment #2 from Brad Roberts bra...@puremagic.com 2011-06-16 00:56:24 PDT --- Fixed: https://github.com/D-Programming-Language/druntime/commit/d3d75983cdd36622ce02338988c35b0ba8b445e9#src/gc/gcx.d DMD also fixed across several commits that greatly improved the accuracy/strictness of the inline assembler checking for 64 bit code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5528] Some integer interval analysis to avoid some casts
http://d.puremagic.com/issues/show_bug.cgi?id=5528 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-16 01:01:05 PDT --- *** This issue has been marked as a duplicate of issue 3147 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3147] Incorrect value range propagation for addition
http://d.puremagic.com/issues/show_bug.cgi?id=3147 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #10 from yebblies yebbl...@gmail.com 2011-06-16 01:01:05 PDT --- *** Issue 5528 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 5176] Limit static object sizes
http://d.puremagic.com/issues/show_bug.cgi?id=5176 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||michel.for...@michelf.com --- Comment #4 from yebblies yebbl...@gmail.com 2011-06-16 01:04:46 PDT --- *** Issue 3677 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 3669] Default parameter initialization of size_t can result in errors about implicit conversions to uint
http://d.puremagic.com/issues/show_bug.cgi?id=3669 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #2 from yebblies yebbl...@gmail.com 2011-06-16 01:11:47 PDT --- Compiles successfully on dmd 2.053 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #5 from Stewart Gordon s...@iname.com 2011-06-16 01:22:22 PDT --- (In reply to comment #3) T*** = const(T***) allowed, full const T*** = const(T**)* allowed, tail const T*** = const(T*)** not allowed T*** = const(T)*** not allowed T*** = T*** allowed, same number of mutable indirections immutable(T*)** = const(T*)** allowed, same number of mutable indirections etc I agree about the first five of these. But I'm not sure if this last one is safe. I'll think about it when I've more time. In any case, see this set of rules I proposed before: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=81566 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 --- Comment #6 from yebblies yebbl...@gmail.com 2011-06-16 01:41:07 PDT --- (In reply to comment #5) I agree about the first five of these. But I'm not sure if this last one is safe. I'll think about it when I've more time. In any case, see this set of rules I proposed before: I haven't been able to think of a way to break it, but that doesn't mean there isn't one! http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=81566 I did find this today. As far as I can tell, this fix combined with the fix for issue 2095 fixes it all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5633] (constfold.c): pointer is null
http://d.puremagic.com/issues/show_bug.cgi?id=5633 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com 2011-06-16 01:50:42 PDT --- *** Issue 6159 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 6159] [CTFE] ICE(constfold.c) on 'is' with structs
http://d.puremagic.com/issues/show_bug.cgi?id=6159 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from yebblies yebbl...@gmail.com 2011-06-16 01:50:42 PDT --- *** This issue has been marked as a duplicate of issue 5633 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5176] Limit static object sizes
http://d.puremagic.com/issues/show_bug.cgi?id=5176 --- Comment #5 from Michel Fortin michel.for...@michelf.com 2011-06-16 06:23:20 EDT --- (In reply to comment #0) To avoid this, static object sizes should be limited to a value that guarantees hardware memory protection (e.g. 64KB). I think on OS X the size of that guaranty is significantly smaller, 4 Kb if I remember well. Is it reasonable to limit structs and objects to 4 Kb on OS X? Note that it's not only structs and objects. Types such as char[100_000]* also pose a risk. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-16 04:23:17 PDT --- B getEnum() is not overriding final A getEnum() It's simply creating a new function. Yet another reason the override attribute should be compulsory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #3 from yebblies yebbl...@gmail.com 2011-06-16 04:43:29 PDT --- This is INVALID, the compiler behaves according to spec. Open an enhancement request if you think the compiler should do something different. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2011-06-16 04:50:59 PDT --- Please yebblies, you are doing a good work, but be generally more careful before closing issues. If Lars Ivar Igesund isn't around now (this was from 2007!) to look at this bug report he may not open an enhancement request! Creating bug report is a lot of work, they often contain important usability insights even when they are wrong. Some times it does less harm to keep them open than to close them by mistake. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 klickverbot c...@klickverbot.at changed: What|Removed |Added Status|RESOLVED|REOPENED CC||c...@klickverbot.at Resolution|INVALID | --- Comment #2 from klickverbot c...@klickverbot.at 2011-06-16 05:11:37 PDT --- Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #5 from yebblies yebbl...@gmail.com 2011-06-16 05:14:26 PDT --- (In reply to comment #4) Please yebblies, you are doing a good work, but be generally more careful before closing issues. If Lars Ivar Igesund isn't around now (this was from 2007!) to look at this bug report he may not open an enhancement request! Creating bug report is a lot of work, they often contain important usability insights even when they are wrong. Some times it does less harm to keep them open than to close them by mistake. Bugzilla is not a sanctuary for ideas. It is a list of issues with the language to be fixed, and possible enhancements to be either incorporated into the language or rejected. Closing a bug report that is invalid does not do harm to anything, the information is still there, the marking is accurate, and the people who might want to propose something similar as a language change are notified (the reporter is emailed, and a notification is posted to the digitalmars.D.bugs list). I don't think anything you've said is a good reason to clutter up bugzilla by leaving an old, invalid bug report open. That being said, I am careful about closing issues. There is no valid bug anywhere in this report. As far as I know this is not a commonly reported complaint nor is there any proposal that would change this behavior. It's simply invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #3 from yebblies yebbl...@gmail.com 2011-06-16 05:18:11 PDT --- (In reply to comment #2) Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #6 from bearophile_h...@eml.cc 2011-06-16 05:22:13 PDT --- Closing a bug report that is invalid does not do harm to anything, the information is still there, I think that in practice you are wrong: with the amount of open bugs, a closed bugs becomes invisible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #4 from klickverbot c...@klickverbot.at 2011-06-16 05:23:12 PDT --- R(In reply to comment #3) (In reply to comment #2) Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? --- Comment #5 from klickverbot c...@klickverbot.at 2011-06-16 05:23:13 PDT --- R(In reply to comment #3) (In reply to comment #2) Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #4 from klickverbot c...@klickverbot.at 2011-06-16 05:23:12 PDT --- R(In reply to comment #3) (In reply to comment #2) Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? --- Comment #5 from klickverbot c...@klickverbot.at 2011-06-16 05:23:13 PDT --- R(In reply to comment #3) (In reply to comment #2) Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #6 from bearophile_h...@eml.cc 2011-06-16 05:25:54 PDT --- Even if D is working according to specs, I think this is bug-prone enough to deserve some warning or even an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3147] Incorrect value range propagation for addition
http://d.puremagic.com/issues/show_bug.cgi?id=3147
--- Comment #11 from bearophile_h...@eml.cc 2011-06-16 05:30:16 PDT ---
This example was in bug 5528:
void main() {
uint i = 10;
ubyte x1 = i % ubyte.max;
ulong l = 10;
uint x2 = l % uint.max;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #7 from yebblies yebbl...@gmail.com 2011-06-16 05:39:11 PDT --- (In reply to comment #6) Closing a bug report that is invalid does not do harm to anything, the information is still there, I think that in practice you are wrong: with the amount of open bugs, a closed bugs becomes invisible. An invalid bug that is closed SHOULD be invisible. If you think there's a valid enhancement in here, open a new bug for it. There is no way we should be keeping invalid bugs open because somebody may have a related enhancement request that they didn't put anywhere in a bug report that they filed four years ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #9 from yebblies yebbl...@gmail.com 2011-06-16 06:32:51 PDT --- (In reply to comment #8) I agree with Bearophile. Moreover, as I see it, a hole in the deprecation system constitutes a bug, just as most of us seem to agree that a hole in the const/immutable system (of which there are many) constitutes a bug. To quote the spec: It is often necessary to deprecate a feature in a library, yet retain it for backwards compatibility. Such declarations can be marked as deprecated, which means that the compiler can be set to produce an error if any code refers to deprecated declarations Where is the code referring to a deprecated declaration? (In reply to comment #5) Bugzilla is not a sanctuary for ideas. It is a list of issues with the language to be fixed, and possible enhancements to be either incorporated into the language or rejected. How is this not an issue with the language to be fixed? The compiler behaves as described in the spec. If it isn't an issue with the language to be fixed, how is it not a possible enhancement to be either incorporated into the language or rejected? What is the requested enhancement? Please, write one up. There isn't one anywhere in this report. That being said, I am careful about closing issues. There is no valid bug anywhere in this report. As far as I know this is not a commonly reported complaint Commonness of reporting is not a criterion for the validity of a bug. No, but I find it a good metric for finding behavior that is bug prone or confusing, and might be worth considering an enhancement request for. nor is there any proposal that would change this behavior. It's simply invalid. No it isn't. And even those that are invalid should, where it makes sense to do so, have their levels changed to enhancement rather than just closed. I would have done that if it made sense to do so. The compiler works as described in the spec within the case in this report. Walter has clarified that this is intentional, and therefore not a bug. If you think the spec and the design of D are not what they should be, that is by definition an enhancement. So please, write one up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #10 from Lars Ivar Igesund larsi...@igesund.net 2011-06-16 06:44:29 PDT --- (In reply to comment #9) To quote the spec: It is often necessary to deprecate a feature in a library, yet retain it for backwards compatibility. Such declarations can be marked as deprecated, which means that the compiler can be set to produce an error if any code refers to deprecated declarations Where is the code referring to a deprecated declaration? It does so implicitly. If you have Bar b = new Foo; and do b.foo(); the compiler will not be able to catch it, as it cannot know whether an arbitrary Bar instance actually is an instance of Foo. So at runtime, a deprecated function will be called, or attempted to be called. The spec probably does not cover this particular usecase, but it seems to me that it is worth a warning. It just doesn't make sense to have an implementation be deprecated, when the same function in the interface is not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449
--- Comment #11 from Stewart Gordon s...@iname.com 2011-06-16 06:45:09 PDT ---
(In reply to comment #9)
(In reply to comment #8)
I agree with Bearophile. Moreover, as I see it, a hole in the deprecation
system constitutes a bug, just as most of us seem to agree that a hole in the
const/immutable system (of which there are many) constitutes a bug.
To quote the spec:
The spec is in itself a place where bugs may exist. Indeed, it's where many of
the bugs in const/immutable are or have been.
It is often necessary to deprecate a feature in a library, yet
retain it for backwards compatibility. Such declarations can be
marked as deprecated, which means that the compiler can be set
to produce an error if any code refers to deprecated declarations
Where is the code referring to a deprecated declaration?
class Foo : Bar {
^
It's an indirect reference, but it's still essentially there.
(In reply to comment #9)
Walter has clarified that this is intentional, and therefore not a
bug.
Where and how?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #7 from yebblies yebbl...@gmail.com 2011-06-16 06:48:41 PDT --- (In reply to comment #5) Remove the �final� attribute and compile the example with -w, and you'll see. I get an error when compiling without the final attribute, -w or not. testx.d(21): Error: function testx.DerivedClass.getEnum of type B() overrides but is not covariant with testx.BaseClass.getEnum of type A() Besides, since when would it be allowed to have two public methods with the same signature? Yes, overloading on return type is disabled for functions in the same scope, but the rules are a little less strict for deriving classes... Looking at the spec, it seems to be explicitly disallowed for functions that would otherwise be virtual. It can be very useful with template functions, as they need to be redefined in each class, and is allowed for static functions. I might be misunderstanding, please post a test case that shows what you mean. (In reply to comment #6) Even if D is working according to specs, I think this is bug-prone enough to deserve some warning or even an error. I think it would be much clearer if override was mandatory, and I'm fairly sure there's already a report for that. If there's something else you'd like, please, write it up. A test case that compiles does not constitute an enhancement request without additional information. (unless it's very, very obvious) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #12 from yebblies yebbl...@gmail.com 2011-06-16 07:22:09 PDT --- (In reply to comment #10) It does so implicitly. If you have Bar b = new Foo; and do b.foo(); the compiler will not be able to catch it, as it cannot know whether an arbitrary Bar instance actually is an instance of Foo. So at runtime, a deprecated function will be called, or attempted to be called. The spec probably does not cover this particular usecase, but it seems to me that it is worth a warning. It just doesn't make sense to have an implementation be deprecated, when the same function in the interface is not. I agree. I think it should be an error to override a non-deprecated function with a deprecated one. It should probably be an error to override a deprecated function with a non-deprecated one too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2011-06-16
07:54:25 PDT ---
I think it is a bug. If the case was that a final function could be masked by
a derived class, then this should compile:
module test;
enum A
{
a = 0,
b = 1
}
class BaseClass
{
final A getEnum()
{
return A.a;
}
}
class DerivedClass : BaseClass
{
A getEnum()
{
return A.b;
}
}
But I get the error:
bug3113.d(19): Error: function test.DerivedClass.getEnum cannot override final
function test.BaseClass.getEnum
This occurs even when I mark DerivedClass' function as final.
I was about to mark this as invalid, citing this as a better example, but since
the compiler complains about masking in this case, I don't see why the original
case is allowed. I believe this kind of thing is allowed in C++.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 klickverbot c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #13 from klickverbot c...@klickverbot.at 2011-06-16 07:56:40 PDT --- What do you think about adding something like this to the spec? �If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.� This would make the use case of �deprecated� clearer, and issues like the above would be definitely bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 --- Comment #7 from Steven Schveighoffer schvei...@yahoo.com 2011-06-16 08:06:02 PDT --- I think the cases are all sound. In order for there to be a problem, both mutable and immutable data need to be castable into const. If you cannot cast mutable into const N references deep, then you can't accidentally rebind it to immutable data. This all stems from being able to treat mutable data as const, and also as mutable at the same time. Being able to treat immutable data as const and immutable at the same time does not cause any harm. This is definitely one of those things that makes my brain hurt... It's like 4 dimensional geometry :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #10 from yebblies yebbl...@gmail.com 2011-06-16 08:09:46 PDT --- (In reply to comment #9) (In reply to comment #8) This occurs even when I mark DerivedClass' function as final. I think it is quite clear that the example you gave shouldn't compile, as the spec has: �Functions marked as final may not be overridden in a derived class, unless they are also private.� The question now is whether the same behavior should also apply to the example from above. I'm strongly in favor of that, because otherwise, there can be situation where the following two pieces of code don't refer to the same �bar()�, which is completely contrary to how classes usually work in D: Would you also apply this rule to static and template functions? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #9 from klickverbot c...@klickverbot.at 2011-06-16 08:06:26 PDT --- (In reply to comment #8) This occurs even when I mark DerivedClass' function as final. I think it is quite clear that the example you gave shouldn't compile, as the spec has: �Functions marked as final may not be overridden in a derived class, unless they are also private.� The question now is whether the same behavior should also apply to the example from above. I'm strongly in favor of that, because otherwise, there can be situation where the following two pieces of code don't refer to the same �bar()�, which is completely contrary to how classes usually work in D: --- auto foo = new Derived(); foo.bar(); --- --- Base foo = new Derived(); foo.bar(); --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5817] rt.lifetime: no generic overflow catching code for _d_newarray(i)T
http://d.puremagic.com/issues/show_bug.cgi?id=5817 --- Comment #4 from Steven Schveighoffer schvei...@yahoo.com 2011-06-16 08:10:02 PDT --- Thanks, Iain. Sorry I didn't get to this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 --- Comment #8 from yebblies yebbl...@gmail.com 2011-06-16 08:14:06 PDT --- (In reply to comment #7) This is definitely one of those things that makes my brain hurt... It's like 4 dimensional geometry :) I had to draw out tables and diagrams before I could get this right in my mind. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #14 from yebblies yebbl...@gmail.com 2011-06-16 08:17:10 PDT --- (In reply to comment #13) What do you think about adding something like this to the spec? �If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.� This would make the use case of �deprecated� clearer, and issues like the above would be definitely bugs. I've always assumed that to be the case, and it should probably be added to the spec, but I don't believe it has any bearing on possible accepts-invalid bugs - they compile anyway as the attribute is effectively ignored. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3113] final overriding
http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #11 from Steven Schveighoffer schvei...@yahoo.com 2011-06-16 08:20:45 PDT --- (In reply to comment #9) (In reply to comment #8) This occurs even when I mark DerivedClass' function as final. I think it is quite clear that the example you gave shouldn't compile, as the spec has: �Functions marked as final may not be overridden in a derived class, unless they are also private.� The question now is whether the same behavior should also apply to the example from above. I don't think this is really overriding. You can still call the base function. It's more like masking. But the compiler is definitely behaving inconsistently, so it's still a bug, either way. I'm strongly in favor of that, because otherwise, there can be situation where the following two pieces of code don't refer to the same �bar()�, which is completely contrary to how classes usually work in D: Would you also apply this rule to static and template functions? I would actually recommend to nix that part of the language, just allow masking of final functions as long as they are not marked override. I.e. final stops the virtual chain, and any derived class will not be able to override the base virtual function. However, it can start up a new chain by *not* specifying override. I think that requiring override is essential to doing something like this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #15 from klickverbot c...@klickverbot.at 2011-06-16 08:44:21 PDT --- (In reply to comment #14) (In reply to comment #13) What do you think about adding something like this to the spec? �If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.� This would make the use case of �deprecated� clearer, and issues like the above would be definitely bugs. I've always assumed that to be the case, and it should probably be added to the spec, but I don't believe it has any bearing on possible accepts-invalid bugs - they compile anyway as the attribute is effectively ignored. If that was stated explicitly in the spec, there is no way this bug could possibly be INVALID, as removing the declaration of foo() in the original example obviously breaks the build, even though it builds fine without �-d� being specified at the command line. Or am I misunderstanding you? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1449] deprecated methods are counted as interface implementation
http://d.puremagic.com/issues/show_bug.cgi?id=1449 --- Comment #17 from klickverbot c...@klickverbot.at 2011-06-16 09:32:19 PDT --- (In reply to comment #16) If that was stated explicitly in the spec, there is no way this bug could possibly be INVALID, as removing the declaration of foo() in the original example obviously breaks the build, even though it builds fine without »-d« being specified at the command line. Or am I misunderstanding you? Sorry! I misread that as 'if the deprecated attribute is removed'. That would definitely make this a bug, but I don't think it's possible. […] I wouldn't regard your example as a problem, because by specifying an »extern« declaration, you are assuring the compiler as the author of »module b« that you will take care of making sure that the function is actually available during linking. The modules a and b are two completely separate entities in your example which just happen to be linked together – the »import a« is not even needed. vtable layouts and class instance sizes are also beyond the scope what »deprecated« as a language-level can possibly provide, but you are right, there _are_ some cases where removing a deprecated declaration could break language guarantees, e.g. for struct members. Regardless, I don't quite see how the »current definition keeps it simple and achievable« – as far as I know, there doesn't even exist a precise definition of »deprecated« right now. All I could find in the spec is the related section on the »Attributes« page ([1]), and »produce an error if any code refers to deprecated declarations« is about as vague as it gets (as confirmed by the fact that we're having this discussion at all). I agree that the wording in my above comment was not quite ideal, but I didn't think too much about it, as it was only intended as a quick suggestion – do you have ideas on how to state this better? Also, don't forget that what I informally described is actually the very raison d'être of »deprecated«: annotate pieces of your API which you are going to remove with it, so clients can see what will break when it'll actually be gone, but can still choose to stick with the current state for a limited amount of time by using the -d flag. As [2] puts it: »This [the deprecated attribute] will make it easy for maintenance programmers to identify any dependence on deprecated features.« [1] http://www.d-programming-language.org/attribute.html#deprecated [2] http://www.d-programming-language.org/overview.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251
--- Comment #9 from Stewart Gordon s...@iname.com 2011-06-16 12:12:23 PDT ---
(In reply to comment #5)
immutable(T*)** = const(T*)** allowed, same number of mutable indirections
As it turns out, this is unsafe, as the following code shows:
--
import std.stdio;
void main() {
immutable(int) i = 42;
immutable(int)* ip = i;
immutable(int)** ipp = ip;
const(int)** cpp = ipp;
int m = 69;
// the next statement makes ip point to a mutable value!
*cpp = m;
writefln(%d, *ip);
m = 105;
writefln(%d, *ip);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #10 from Andrei Alexandrescu and...@metalanguage.com 2011-06-16 12:23:01 PDT --- Yah, this has constantly puzzled starting C++ programmers - you can convert char* to const(char*) but not char** to const(char*)*. Generally, consider types P (permissive) and N (nonpermissive). Assume both types have the same structure, so there is no matter of converting representation. Generally you can't convert the address of a N to the address of a P even if you can actually convert a N to an P. This is because the address conversion would allow you subsequent P-specific operations directly against an N object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6164] New: [CTFE] Local arrays in a recursive local function behave funny
http://d.puremagic.com/issues/show_bug.cgi?id=6164
Summary: [CTFE] Local arrays in a recursive local function
behave funny
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-06-16 12:40:49 PDT ---
This is tt.d:
import std.stdio;
string ctfe(){
int[] ctfe2(int n){
int[] r=[];
if(n!=0) r~=[1]~ctfe2(n-1);
return r;
}
return ctfe2(2).length == 2 ?
hello from runtime! : hello from compile time!;
}
void main(){
pragma(msg,ctfe());
writeln(ctfe());
}
$ dmd -run tt;
hello from compile time!
hello from runtime!
$
The ctfe'd result is generally longer than the correct one.
The example works as expected if ctfe2 is moved outside ctfe.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6164] [CTFE] Local arrays in a recursive local function behave funny
http://d.puremagic.com/issues/show_bug.cgi?id=6164 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #1 from kenn...@gmail.com 2011-06-16 13:07:12 PDT --- A workaround is to make ctfe2 a 'static function'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 --- Comment #11 from Stewart Gordon s...@iname.com 2011-06-16 13:18:31 PDT --- (In reply to comment #10) Yah, this has constantly puzzled starting C++ programmers - you can convert char* to const(char*) but not char** to const(char*)*. Do you mean char** to const(char)** ? Generally, consider types P (permissive) and N (nonpermissive). Assume both types have the same structure, so there is no matter of converting representation. Generally you can't convert the address of a N to the address of a P even if you can actually convert a N to an P. This is because the address conversion would allow you subsequent P-specific operations directly against an N object. Well said. Converting T* (N) to const(T)* (P) is safe. The P-specific operation is rebinding it to an immutable(T). So converting T** to const(T)** is unsafe. Similarly, Converting immutable(T)* (N) to const(T)* (P) is safe. The P-specific operation is rebinding it to a mutable T. So converting immutable(T)** to const(T)** is unsafe. This is the principle that underlies all these proposed rules - whether the indirection is a pointer, dynamic array or other container type, and whether the N-P is a constancy change or a walk up the class hierarchy. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6165] New: Anonymous enums specification
http://d.puremagic.com/issues/show_bug.cgi?id=6165
Summary: Anonymous enums specification
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright bugzi...@digitalmars.com 2011-06-16
14:00:25 PDT ---
I believe there is an omission in the D specification document. The page for
enums specification http://d-programming-language.org/enum.html defines enum
body syntax as follows:
EnumBody:
;
{ EnumMembers }
Should it not be
EnumBody:
EnumMember ;
{ EnumMembers }
or perhaps
EnumBody:
EnumMembers ;
{ EnumMembers }
Otherwise, I can't quite grasp how following enums definitions are legal:
enum X = 4;
enum
mega = 1024 * 1024,
pi = 3.14,
euler = 2.72,
greet = Hello;
(Both of the above enums are accepted by dmd v2.050).
Regards,
Lennart
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6166] New: Named return value optimization not dealt with in inline assembler
http://d.puremagic.com/issues/show_bug.cgi?id=6166
Summary: Named return value optimization not dealt with in
inline assembler
Product: D
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright bugzi...@digitalmars.com 2011-06-16
14:24:00 PDT ---
Byron writes:
I reduced the complexity of the problem, seems to be SSE and returning local
copies.
$ dmd -run db.d
v: [1, 2, 3, 4]
test1 r: [nan, nan, nan, nan]
test1: [nan, nan, nan, nan]
test2 r: [1, 2, 3, 4]
test2: [1, 2, 3, 4]
halle109-251:asm byro
//db.d
import std.stdio;
alias float[4] vector;
const(vector) test1( ref const(vector) v )
{
vector r;
asm
{
mov EAX, v;
movups XMM0, [EAX];
movups r, XMM0;
}
writeln( test1 r: , r );
return r;
}
const(vector) test2( ref const(vector) v )
{
vector r, s;
asm
{
mov EAX, v;
movups XMM0, [EAX];
movups r, XMM0;
}
writeln( test2 r: , r );
s = r;
return s;
}
void main()
{
vector v = [1,2,3,4];
writeln( v: , v );
writeln( test1: , test1(v));
writeln( test2: , test2(v));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6167] New: RefCounted and lazy/delegate
http://d.puremagic.com/issues/show_bug.cgi?id=6167
Summary: RefCounted and lazy/delegate
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jsan...@gmail.com
--- Comment #0 from Jose Garcia jsan...@gmail.com 2011-06-16 15:57:31 PDT ---
I am not sure what is going but this maybe a dmd bug so filing here. The
following program:
import std.typecons;
import std.exception;
struct Struct
{
this(int dummy) { refCount = RefCounted!Impl(Impl(dummy)); }
~this() {}
RefCounted!Impl refCount;
struct Impl { int dummy; }
Struct fun(bool now)
{
if(now) throw new Exception();
return Struct(1);
}
}
void lazyFun(lazy Struct exp)
{
try { exp(); } catch(Exception e) {}
}
void delegateFun(Struct delegate() exp)
{
try { exp(); } catch(Exception e) {}
}
void main()
{
auto var = Struct(1);
try { auto result = var.fun(true); } catch(Exception e) {}
delegateFun({ return var.fun(true); }); // segfaults
lazyFun(var.fun(true)); // segfaults
assertThrown(var.fun(true)); // segfaults
}
Produces the following nonsensical output:
_RefCounted@95F9410: initialized with (Impl _param_0)
RefCounted!(Impl)@B74B8E40: decrement refcount to 157258767
RefCounted!(Impl)@B74B8E40: decrement refcount to 157258766
RefCounted!(Impl)@95F940E: decrement refcount to 65535
Notice the value of the refcount!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6167] RefCounted and lazy/delegate
http://d.puremagic.com/issues/show_bug.cgi?id=6167
--- Comment #1 from Jose Garcia jsan...@gmail.com 2011-06-16 16:00:39 PDT ---
Also, note that if change fun to not be a member function you get the
following:
struct Struct
{
this(int dummy) { refCount = RefCounted!Impl(Impl(dummy)); }
~this() {}
RefCounted!Impl refCount;
struct Impl { int dummy; }
}
Struct fun()
{
throw new Exception();
}
//...
$ ../dmd/dmd/src/dmd -debug=RefCounted -w -gc ref_test.d
../dmd/phobos/std/typecons.d ./ref_test
_RefCounted@89A8410: initialized with (Impl _param_0)
RefCounted!(Impl)@89A8410: freeing... done!
Which is the expected result.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6168] New: Regression (2.047): Cannot create enum of struct with constructor
http://d.puremagic.com/issues/show_bug.cgi?id=6168
Summary: Regression (2.047): Cannot create enum of struct with
constructor
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: johann.macdon...@gmail.com
--- Comment #0 from Johann MacDonagh johann.macdon...@gmail.com 2011-06-16
16:33:33 PDT ---
struct Test
{
this(int a)
{
}
}
void main()
{
enum a = Test(5);
}
This compiled on 2.046 but no longer does. The error messages have changed over
the versions, but current 2.053 complains:
test.d(10): Error: variable __ctmp3 cannot be read at compile time
test.d(10): Error: cannot evaluate __ctmp3.this(5) at compile time
enum a = Test();
This works fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6169] New: [CTFE] pure functions cannot compute constants using functions not marked as pure
http://d.puremagic.com/issues/show_bug.cgi?id=6169
Summary: [CTFE] pure functions cannot compute constants using
functions not marked as pure
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-06-16 17:09:25 PDT ---
With DMD 2.053:
string impure(){return ;;}
void main() pure{
enum s = impure(); // fail (cannot call impure function 'impure')
mixin(impure()); // ditto
}
Removing the pure attribute from 'main' or adding it to 'impure' makes the code
pass.
This restriction is nonsensical and should be removed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6169] [CTFE] pure functions cannot compute constants using functions not marked as pure
http://d.puremagic.com/issues/show_bug.cgi?id=6169
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2011-06-16 18:42:49 PDT ---
I think you have just made D a bit more complex :-)
In D compile time and run time are fully separated (and computing an enum
inside a CTFE function spans a fully separated and fully enclosed
sub-computation), so there is no way compile-time constants can break the
purity of a pure function. So this looks OK regarding run-time purity.
Currently in D in a function the path of compile-time execution has to be pure,
even if the whole function is not pure, so you are right saying this program
has to compile:
int x = 10;
int foo(bool b) {
if (b)
x++;
return 0;
}
pure void main() {
enum y = foo(false);
}
If in future D compilers CTFE will be allowed to modify global variables too,
then I think your idea is in troubles. Otherwise at first sight it seems OK,
but more thinking is required because future D compilers are allowed to perform
pure-related optimizations on pure functions even in CTFE. Is nonpurity able to
cause troubles to pure functions at compile-time?
In this program spam is pure, and it calls bar, that's not pure, to compute z.
But this program doesn't cause troubles even if a smart D compiler applies pure
optimization of spam()+spam() replacing it with spam()*2 because z is computed
only once, because bar() is called in a sub-computation that's fully sealed:
pure nothrow int foo() {
int x = 1;
nothrow int bar(int y) { // nonpure
x++;
return x + y;
}
pure nothrow int spam() {
enum z = bar(1); // calls a nonpure
return z;
}
return spam() + spam();
}
enum r = foo();
void main() {}
So if I am right, then this proposal is safe :-)
One problem left is that this proposal introduces another special case in D,
because the rules of purity have to say a pure function is allowed to call an
impure one at compile-time. Is it worth it? I think it's acceptable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=4251 --- Comment #12 from yebblies yebbl...@gmail.com 2011-06-16 20:18:02 PDT --- (In reply to comment #9) (In reply to comment #5) immutable(T*)** = const(T*)** allowed, same number of mutable indirections As it turns out, this is unsafe, as the following code shows: Good catch! I'll get on it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
