[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #18 from Denis Shelomovskij verylonglogin@gmail.com 2012-07-09 10:36:11 MSD --- (In reply to comment #17) It looks like we've decided that Win2k is not supported anymore. We will probably go with the official policy of only supporting versions of Windows that Microsoft still supports. Reopened, because the issue is that there is no notes in changelog/download pages and this confuses D users. As I wrote: Please write supported operating systems somewhere in plain view (e.g. in Requirements and Downloads section of http://www.digitalmars.com/d/2.0/dmd-windows.html). And in write in changelog ... OS is not supported any more. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7894] [CTFE] - goto within ForStatement restarts loop
http://d.puremagic.com/issues/show_bug.cgi?id=7894
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don clugd...@yahoo.com.au 2012-07-09 01:28:00 PDT ---
Slightly reduced test case:
int bug7894()
{
for (int k = 0; k 2; ++k) {
goto Lagain;
Lagain: ;
}
return 1;
}
static assert( bug7894() );
Actually the loop initializer isn't reinterpreted after each goto. What's
happening is that the increment is skipped.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8363] New: Provide an intutive way to clear all entries in Associative Array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 Summary: Provide an intutive way to clear all entries in Associative Array Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: pun...@coverify.org --- Comment #0 from Puneet Goel pun...@coverify.org 2012-07-09 06:22:08 PDT --- Deleting all the entries from an associative array is not intuitive. This has been discussed at the D forum here: http://forum.dlang.org/thread/iu3ll6$2d48$1...@digitalmars.com I suggest the following syntax should work int[string] aa; aa[foo] = 1; aa = []; // clear all array entries At this point only this works. I think this is not very intuitive. int[string] aa; int[string] empty; aa[foo] = 1; aa = empty; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8363] Provide an intutive way to clear all entries in Associative Array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from timon.g...@gmx.ch 2012-07-09 06:49:35 PDT --- aa.clear() should work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8363] Provide an intutive way to clear all entries in Associative Array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 --- Comment #2 from Puneet Goel pun...@coverify.org 2012-07-09 07:11:51 PDT --- (In reply to comment #1) aa.clear() should work. I had not tried it because the forum topic (only one year old) said that it does not worl. But it does seem too work now. Can we add that to the Assoc array documentation here http://dlang.org/hash-map.html ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8363] Empty array literal does not implicitly convert to associative array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Summary|Provide an intutive way to |Empty array literal does |clear all entries in|not implicitly convert to |Associative Array |associative array --- Comment #3 from yebblies yebbl...@gmail.com 2012-07-10 01:54:12 EST --- (In reply to comment #0) aa = []; // clear all array entries This should probably work. At this point only this works. I think this is not very intuitive. int[string] aa; int[string] empty; aa[foo] = 1; aa = empty; try aa = null; But be careful, don't forget AAs are reference types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6834] std.stdio conflicts with core.stdc.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=6834 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #5 from yebblies yebbl...@gmail.com 2012-07-10 01:59:56 EST --- This is not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6186] Struct destructor is not called on out parameter
http://d.puremagic.com/issues/show_bug.cgi?id=6186 Benjamin Thaut c...@benjamin-thaut.de changed: What|Removed |Added CC||c...@benjamin-thaut.de --- Comment #3 from Benjamin Thaut c...@benjamin-thaut.de 2012-07-09 09:22:23 PDT --- Why is the github merge request closed? This issue is not fixed yet and the current behaviour leads to really strange bugs... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #76 from yebblies yebbl...@gmail.com 2012-07-10 02:54:06 EST ---
(In reply to comment #55)
Unfortunately, I do not currently see a reasonable way of implementing this.
Fortunately, as is it does not inhibit correct programs, it only accepts some
invalid ones.
I can't see any way to do it without changing the abi for virtual functions
with contracts.
But, if changing the abi was ok, I think something like this would work:
class A
{
void func(..., __in_contract_ptr)
{
void __nested_in_contract_A_func() { ... }
auto __in_contract = __nested_in_contract_A_func;
__in_contract.ptr = ptr;
__in_contract();
...
}
}
class B : A
{
void func(..., __in_contract_ptr)
{
void __nested_in_contract_B_func() { ... }
auto __in_contract = __nested_in_contract_B_func;
__in_contract.ptr = ptr;
__in_contract();
...
}
}
void main()
{
B b = new B();
b.func(..., __nested_in_contract_B_func.ptr);
A a = b;
a.func(..., __nested_in_contract_A_func.ptr);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8363] Empty array literal does not implicitly convert to associative array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-09 10:45:46 PDT --- aa.clear() should work. I believe that that's the same as setting it to null. It doesn't actually remove anything from the AA. It just makes that reference null. If you want to actually remove all of the elements from the AA, you currently have to iterate over them and call remove on each one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8363] Empty array literal does not implicitly convert to associative array
http://d.puremagic.com/issues/show_bug.cgi?id=8363 --- Comment #5 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-09 11:02:47 PDT --- However, with clear being renamed to destroy for 2.060 (with clear scheduled for deprecation), I don't see any problem with adding a clear function to AAs which actually clears the AA (that's probably what most everyone using clear on AAs wanted anyway). Presumably, that could be done as part of the AA implementation redesign that's currently being worked on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #77 from Stewart Gordon s...@iname.com 2012-07-09 11:12:52 PDT --- (In reply to comment #76) I can't see any way to do it without changing the abi for virtual functions with contracts. What about my suggestion of comment 61? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #78 from yebblies yebbl...@gmail.com 2012-07-10 04:43:07 EST --- (In reply to comment #77) (In reply to comment #76) I can't see any way to do it without changing the abi for virtual functions with contracts. What about my suggestion of comment 61? As Walter said, that requires argument forwarding, which introduces copying problems and doesn't work with variadics. The precondition needs to be evaluated in the context of the function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8364] New: Allow exclamation mark in template definition
http://d.puremagic.com/issues/show_bug.cgi?id=8364
Summary: Allow exclamation mark in template definition
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: qwertie...@gmail.com
--- Comment #0 from David Piepgrass qwertie...@gmail.com 2012-07-09 13:12:42
PDT ---
The syntax of templates should be similar at the definition as it is at the
call site:
T sum!(T,R)(R range) if (isInputRange!R...) { ... }
Of course, the existing syntax must be kept too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8364] Allow exclamation mark in template definition
http://d.puremagic.com/issues/show_bug.cgi?id=8364 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-09 13:25:16 PDT --- Of what value is that? The current situation is wonderfully unambiguous. This proposal would make the parser's life harder and would probably make it so that the grammar could no longer be context free (which would be very bad). And from the perspective of the programmer (not just the compiler), it's _useful_ to be able to tell the difference between a template and a template instantiation at a glance. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8364] Allow exclamation mark in template definition
http://d.puremagic.com/issues/show_bug.cgi?id=8364 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #3 from timon.g...@gmx.ch 2012-07-09 13:36:26 PDT --- (In reply to comment #2) Of what value is that? The current situation is wonderfully unambiguous. True. This proposal would make the parser's life harder Not really. Having this as the only template declaration syntax would even make the parser's life easier. (and if both were legal, parsing the kind that has the '!' would be slighly more efficient.) and would probably make it so that the grammar could no longer be context free This is not the case. The grammar would stay context free. (which would be very bad). And from the perspective of the programmer (not just the compiler), it's _useful_ to be able to tell the difference between a template and a template instantiation at a glance. The proposal does not put this ability in danger. Anyway, I don't prefer either scheme and in my opinion it is fine to either leave the template declaration grammar as it is, or to change it to always require '!'. The latter is not going to happen though. (I remember that when I wrote my very first function template in D, I used the proposed syntax and was confused that it didn't work.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8365] New: Static fixed size array of enums initialization fails
http://d.puremagic.com/issues/show_bug.cgi?id=8365
Summary: Static fixed size array of enums initialization fails
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tommitiss...@hotmail.com
--- Comment #0 from Tommi tommitiss...@hotmail.com 2012-07-09 14:49:44 PDT ---
module main;
immutable(int[2]) ints =
{
int[2] tempInts; // #0: OK
for (int i = 0; i 2; ++i)
{
tempInts[i] = i;
}
return cast(immutable) tempInts;
}(); // #1: OK
enum MyEnum { first, second, third, fourth }
immutable(MyEnum[2]) enums =
{
MyEnum[2] tempEnums; // #2
for (int i = 0; i 2; ++i)
{
tempEnums[i] = cast(MyEnum) i;
}
return cast(immutable) tempEnums;
}(); // #3
void main(string[] args)
{
}
// #2: Error: Array length mismatch assigning [0..0] to [0..2]
// #3: Error: called from here: (*delegate pure nothrow @safe
immutable(MyEnum[2u])()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #79 from Stewart Gordon s...@iname.com 2012-07-09 15:22:23 PDT --- (In reply to comment #78) As Walter said, that requires argument forwarding, which introduces copying problems and doesn't work with variadics. I thought I'd debunked that, but you're right. By my proposal, user code would be calling either foo_dbc or foo depending on whether it's compiled in dev or release mode. And foo_dbc forwards to foo. But it does seem to be down to two problems with D's design: - structs aren't guaranteed to be safe to just bit-copy (this problem was introduced in D2) - we have variadics that are really just C's variadics with typeinfo added Something else I should've realised earlier: Why do D class methods need to be directly callable from C? (How does C code hold a reference to a D object, anyway?) Indeed, is even C++ designed to accommodate this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.
http://d.puremagic.com/issues/show_bug.cgi?id=7021
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
Severity|normal |major
--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-09 20:22:25
PDT ---
This works just fine too (with dmd 2.060HEAD)
struct Foo
{
@disable this();
}
void main()
{
auto foo = Foo.init;
}
It looks to me like @disable this() isn't working at all.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #80 from yebblies yebbl...@gmail.com 2012-07-10 14:02:54 EST --- (In reply to comment #79) (In reply to comment #78) But it does seem to be down to two problems with D's design: - structs aren't guaranteed to be safe to just bit-copy (this problem was introduced in D2) - we have variadics that are really just C's variadics with typeinfo added We also have C's variadics. Something else I should've realised earlier: Why do D class methods need to be directly callable from C? (How does C code hold a reference to a D object, anyway?) Indeed, is even C++ designed to accommodate this? COM classes defined in D are callable from C (and you could define other classes the same way). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8366] New: Overriding const member function in conjunction with mutable overload causes a strange error
http://d.puremagic.com/issues/show_bug.cgi?id=8366
Summary: Overriding const member function in conjunction with
mutable overload causes a strange error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-07-09 21:26:12 PDT ---
I think this problem blocks 2.060 release.
code:
class C {
// overrides Object.opEquals
bool opEquals(const Object o) const {}
// introduce mutable overload
bool opEquals(const Object o) {} // line8
}
void main(){}
output:
test.d(8): Error: function test.C.opEquals multiple overrides of same function
The second opEquals should *introduce* new member function. But, by the const
attribute inference, it is determined as *multiple overrides.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8366] Overriding const member function in conjunction with mutable overload causes a strange error
http://d.puremagic.com/issues/show_bug.cgi?id=8366 Benjamin Thaut c...@benjamin-thaut.de changed: What|Removed |Added CC||c...@benjamin-thaut.de --- Comment #1 from Benjamin Thaut c...@benjamin-thaut.de 2012-07-09 22:01:38 PDT --- I reported the same issue with shared a while back, and it was stated that this is intentional. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
