[Issue 693] 'this' can't be used as an alias parameter for a mixin
http://d.puremagic.com/issues/show_bug.cgi?id=693 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-07-01 00:31:09 PDT --- https://github.com/D-Programming-Language/dmd/commit/5a1f396e915e083ce30c5f09f4e1ef1a9e704fda https://github.com/D-Programming-Language/dmd/commit/c9e26681a834beb6b211f41234163707453f4ff1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5946] failing lookup 'this' from function in template
http://d.puremagic.com/issues/show_bug.cgi?id=5946 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-07-01 00:34:37 PDT --- https://github.com/D-Programming-Language/dmd/commit/5a1f396e915e083ce30c5f09f4e1ef1a9e704fda -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5946] failing lookup 'this' from function in template
http://d.puremagic.com/issues/show_bug.cgi?id=5946 --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-07-01 00:36:46 PDT --- https://github.com/D-Programming-Language/dmd/commit/5a1f396e915e083ce30c5f09f4e1ef1a9e704fda -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5946] failing lookup 'this' from function in template
http://d.puremagic.com/issues/show_bug.cgi?id=5946 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2011-07-01 01:07:40 PDT --- https://github.com/D-Programming-Language/dmd/commit/8359ec9e14dc7294360d954325aacd4dcaed35c7 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1692] Abstract class dynamic creation bug
http://d.puremagic.com/issues/show_bug.cgi?id=1692 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Component|DMD |druntime Platform|x86 |All OS/Version|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com 2011-07-01 19:57:29 EST --- The bug is primarily in druntime, but requires a dmd change to pass more information along. https://github.com/D-Programming-Language/dmd/pull/186 https://github.com/D-Programming-Language/druntime/pull/34 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #5 from Don clugd...@yahoo.com.au 2011-07-01 03:12:01 PDT --- (In reply to comment #4) Shouldn't opCmp be relaxed like opEquals in bug 3659? It is indeed the same issue. But I'm not convinced by the proposed solution in bug 3659. We don't need more options -- we just need one GOOD one. IMHO, this is *the* remaining black hole in the language. We have a zoo of parameter passing options -- in, inout, out, ref, const ref, auto ref -- and yet it's not possible to express the most basic parameter passing option: I want read-only access from this value, and I give the compiler freedom to pass it as efficiently as possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6139] Duplicate error message on compile-time out of bounds array index
http://d.puremagic.com/issues/show_bug.cgi?id=6139 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch Severity|normal |trivial --- Comment #1 from yebblies yebbl...@gmail.com 2011-07-01 20:48:49 EST --- https://github.com/D-Programming-Language/dmd/pull/187 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4274] Better array of inner structs error message
http://d.puremagic.com/issues/show_bug.cgi?id=4274 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|x86 |All Resolution||FIXED OS/Version|Windows |All --- Comment #6 from yebblies yebbl...@gmail.com 2011-07-01 21:52:59 EST --- Arrays of nested structs are now allowed (dmd 1.068 dmd 2.053) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6234] New: 64-bit array append generates inline code to copy new data, but does not call postblit
http://d.puremagic.com/issues/show_bug.cgi?id=6234 Summary: 64-bit array append generates inline code to copy new data, but does not call postblit Product: D Version: D2 Platform: x86_64 OS/Version: All Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: schvei...@yahoo.com --- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2011-07-01 05:38:11 PDT --- The 64-bit compiler no longer calls _d_arrayappendT directly, it now calls _d_arrayappendCTX, which does *not* copy the new data to the array. This is fine, because the compiler generates the necessary code to copy the new data. However, the compiler does *not* call postblit on that data. Two ways to fix this: 1. Simply switch to calling _d_arrayappendT again, and don't do the copying inline. 2. Insert a call to __doPostblit (or whatever you want to rename it, it's in rt/lifetime.d) after copying the data, but only if the type *has* a valid postblit. This is the reason the runtime is currently failing unit tests on 64-bit code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4466] std.conv: parse!(T, S)(S, uint radix) the opposite of to to!(T, S)(S, uint radix)
http://d.puremagic.com/issues/show_bug.cgi?id=4466 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #3 from yebblies yebbl...@gmail.com 2011-07-01 22:55:23 EST --- Closing as the function is now in phobos and works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4539] Refuse assignment to string literal
http://d.puremagic.com/issues/show_bug.cgi?id=4539 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All OS/Version|Windows |All --- Comment #11 from yebblies yebbl...@gmail.com 2011-07-01 23:36:13 EST --- A new patch that reapplies the old one and fixes the failing tests: https://github.com/D-Programming-Language/dmd/pull/188 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5003] regex(replace with delegate) sample doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=5003 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||rejects-valid Status|RESOLVED|REOPENED CC||yebbl...@gmail.com Platform|Other |All Resolution|WORKSFORME | OS/Version|Windows |All --- Comment #2 from yebblies yebbl...@gmail.com 2011-07-02 04:09:49 EST --- Reopened as the reason it works is that the bug has been worked around in phobos, not fixed. It still needs to be reduced with an older version of phobos, or possibly closed as a duplicate. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5719] [patch] std.conv.to should support structs with custom converters in addition to objects
http://d.puremagic.com/issues/show_bug.cgi?id=5719 --- Comment #1 from Rob Jacques sandf...@jhu.edu 2011-07-01 13:04:20 PDT --- I've noticed that with generic code that Target toImpl(Target, Source)(Source value) if (implicitlyConverts!(Source, Target)) can cause an error via multiple template matches with T toImpl(T, S)(S value) if (is(S : Object) is(T : Object)) and T toImpl(T, S)(S value) if (((is(S : Object) !is(T : Object)) || is(S == struct)) !isSomeString!T is(typeof(S.init.to!(T)()) : T)) Both issues can be simply fixed by adding an additional template constraint: !implicitlyConverts!(S,T) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5719] [patch] std.conv.to should support structs with custom converters in addition to objects
http://d.puremagic.com/issues/show_bug.cgi?id=5719 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com Severity|normal |enhancement --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-01 13:12:48 PDT --- There are several pull requests affect std.conv.to at the moment which will change the situation and which will likely be merged in soon. Among other things, they get rid of the member function to conversion and make std.conv.to work with overloaded opCast. https://github.com/D-Programming-Language/phobos/pull/118 https://github.com/D-Programming-Language/phobos/pull/119 https://github.com/D-Programming-Language/phobos/pull/122 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6235] New: Regression(DMD 2.053) ICE on typeof(Range.init[0..$]) inside a templated struct/class
http://d.puremagic.com/issues/show_bug.cgi?id=6235
Summary: Regression(DMD 2.053) ICE on typeof(Range.init[0..$])
inside a templated struct/class
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-valid-code
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2011-07-01 13:51:56 PDT ---
This is a regression between DMD 2.052 and DMD 2.053. Here is a very reduced
test case:
struct Bug(Range) { pragma(msg, typeof(Range.init[0..$]) ); }
void main(string[] args) {
Bug!(ubyte[]) bug;
}
The issue also effect classes and is statements, i.e.
enum useSlicing = is(typeof(Range.init[0..$]) : const ubyte[] );
This problem seems to be limited to the use of a template parameter inside a
struct/class defined outside of the current scope. All of the following
compile:
void main(string[] args) {
pragma(msg, typeof((ubyte[]).init[0..$]) );
alias ubyte[] Range;
pragma(msg, typeof(Range.init[0..$]) );
struct NotBug(Range2) { pragma(msg, typeof(Range2.init[0..$]) ); }
NotBug!(ubyte[]) notBug;
}
This bug can be worked around by placing the statement inside its own
sub-template. I.e:
struct Bug(Range) {
template UseSlicing(__Range) {
enum UseSlicing = is(typeof(__Range.init[0..$]) : const ubyte[] );
}
pragma(msg, UseSlicing!Range);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6235] Regression(DMD 2.053) ICE on typeof(Range.init[0..$]) inside a templated struct/class
http://d.puremagic.com/issues/show_bug.cgi?id=6235 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2011-07-01 14:36:38 PDT --- It's crashing in VoidInitializer::toDt(). Seems that 'type' hasn't been set. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6236] New: Subtle bug with Windows timer, hashes and imports
http://d.puremagic.com/issues/show_bug.cgi?id=6236 Summary: Subtle bug with Windows timer, hashes and imports Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 16:01:12 PDT --- !!PLEASE BE CAREFUL!! I've tested this on my own system, and it just crashes the app. But I've also tested it in a VirtualBox on Win7 and it completely froze the system. This is the smallest test case I could make, you'll have to download it from: https://github.com/AndrejMitrovic/temporary/tree/master/hashbug Extract the hashbug folder, build the app with build.bat, and then keep resizing the window for a few seconds. In just a couple of seconds there's a crash with: --- hashbug.exe - Application Error --- The instruction at 0x00403b39 referenced memory at 0x000c. The memory could not be read. --- First of all, it doesn't matter that there's no WinMain function here, WinMain is just a convention and the bug can be recreated with a WinMain function as well. If you comment out import std.utf; the bug disappears, even though std.utf is never used in the module. If you change the static hash in BugCallback with a globally shared one __gshared int[int] hash; outside the function then the bug seems to go away. If you replace the line static int[1] arr = [1]; in BugCallback with static int[1] arr = [0];, then the crash only happens when exiting. If you comment out hash[arr[0]] = 0; in BugCallback, the bug disappears. If you replace that line with hash[0] = 0;, then the crash only happens when exiting. If you comment out the line foo ~= 1; in a completely different function BugFunction that runs in another thread, the bug disappears. That function keeps expanding an array, but it doesn't cause a stackoverflow or anything. DDBG shows this: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc005) at __aaGetX (0x00403b39) thread(2728) aaGetX looks like a Hash function from Druntime. So my guess is the hash does something that doesn't work quite well with the Windows timer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5962] Template function declaration with prefixed storage class and auto occurs conflict
http://d.puremagic.com/issues/show_bug.cgi?id=5962 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-07-01 18:18:21 PDT --- https://github.com/D-Programming-Language/dmd/commit/781df821312d9350e9e750993b77ff43c0c8e30d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-07-01 18:24:24 PDT --- I don't think it's right to make foreach_reverse crippled compared with foreach. I'm going to mark as won't fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553
--- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com 2011-07-01
18:29:03 PDT ---
Walter, did you understand the bug report correctly? My 4-year-old explanation
could have been better, but what I meant is that:
foreach (v; someDelegate) { ... }
did the exact same thing as
foreach_reverse (v; someDelegate) { ... }
Someone may try to use foreach_reverse intuitively over a delegate, hoping
it'll just work, and get unexpected results (as I have 4 years ago).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-07-01 18:48:10 PDT --- Yes, I understood your point. I agree that one could make an error this way. I disagree that the solution is to remove the feature. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2011-07-01 18:50:16 PDT --- Why? This is clearly an accepts-invalid bug! What would a better solution be, anyway? reverse_delegate? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6059] Incompatible types in array literal shows __error and error
http://d.puremagic.com/issues/show_bug.cgi?id=6059 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-07-01 19:09:59 PDT --- https://github.com/D-Programming-Language/dmd/commit/d82506e803d6cc2979639fda5a678c29ca995009 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2011-07-01 19:16:27 PDT --- The compiler cannot tell what the delegate does, so there's no way it can diagnose an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com 2011-07-01 19:18:00 PDT --- Exactly! We can only assume that all delegates are written for forward iteration. I am having trouble understanding your problem with disabling foreach_reverse with delegates specifically. You say it'd be removing a feature, but how can it be a feature if it neither is nor can be implemented? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-01 19:32:08 PDT --- But why couldn't a delegate be written for reverse iteration? And if it does exactly the same thing for both foreach and foreach_reverse, I don't really see the problem. Granted, it may be a bit weird, but I don't see the bug. Though truth be told, I've been wondering whether foreach_reverse is actually supposed to be sticking around, given the general move towards ranges and the fact that foreach_reverse isn't actually mentioned in TDPL (at least, it's not in the index). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553
--- Comment #9 from Vladimir Panteleev thecybersha...@gmail.com 2011-07-01
19:38:33 PDT ---
(In reply to comment #8)
But why couldn't a delegate be written for reverse iteration?
So put the semantics in the delegate name, instead of expecting the user to
always use the correct one of the two semantically-opposite but actually
synonymous keywords. This can easily become a point of confusion, and I'm
surprised I need to elaborate in so much detail why this is plain bad.
What's wrong with writing it like this?
foreach (v; foo.reverseIterator) { ... }
If you start writing it like this:
foreach_reverse (v; foo.reverseIterator)
Sooner or later someone will forget the second reverse, the code will look
and compile right, and work wrong!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2011-07-01 19:39:51 PDT --- (In reply to comment #8) But why couldn't a delegate be written for reverse iteration? Exactly. It can be. Why take this away? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 --- Comment #11 from Vladimir Panteleev thecybersha...@gmail.com 2011-07-01 19:41:10 PDT --- (In reply to comment #10) Exactly. It can be. Why take this away? You get the same thing by putting the semantic in the delegate name, without risking bugs and misunderstanding. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4258] auto ref doesn't work in one or more cases
http://d.puremagic.com/issues/show_bug.cgi?id=4258 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-07-01 19:52:49 PDT --- https://github.com/D-Programming-Language/dmd/commit/ef3c8386ede421aa2756820eebc70dd03c9e58e1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6237] New: htod generates invalid module name and declaration
http://d.puremagic.com/issues/show_bug.cgi?id=6237 Summary: htod generates invalid module name and declaration Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: htod AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 21:42:22 PDT --- E.g.: htod cairo-win32.h generates cairo-win32.d This won't compile. I think a safe option would be to convert to underscores: cairo_win32.d and also do the same for the module declaration in the file. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6237] htod generates invalid module name and declaration
http://d.puremagic.com/issues/show_bug.cgi?id=6237 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 21:43:48 PDT --- Ah but I can already do this: htod cairo-win32.h cairo_win32.d I guess I should close it then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6238] New: Cannot define global immutable AA
http://d.puremagic.com/issues/show_bug.cgi?id=6238
Summary: Cannot define global immutable AA
Product: D
Version: D2
Platform: Other
OS/Version: Windows
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-07-01
21:54:32 PDT ---
I *believe* this bug has been discussed and reported before, but a search
didn't turn up anything. This code fails to compile:
immutable test = // auto, const, etc.. also fail
[
'a' : 1,
'b' : 2,
];
void main()
{
}
On 2.053 we get:
main.d(2): Error: non-constant expression ['a':1,'b':2]
A workaround is to do:
enum test =
[
'a' : 1,
'b' : 2,
];
void main()
{
auto localTest = test;
// Use either test or localTest
}
But of course that will cause test to be copied each time it is referenced
(which, besides all the drama in issue 4397 I believe to be correct).
The reason this matters is because of CTFE. If I have an AA which I want to be
able to use in CTFE and at runtime without causing copies to be made at runtime
I'd have to use an immutable AA.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1373] typeof(func).stringof fails when func has parameters.
http://d.puremagic.com/issues/show_bug.cgi?id=1373 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-07-01 22:13:17 PDT --- https://github.com/D-Programming-Language/dmd/commit/28702b21e143807205f6798b000a0c05bb22d5e2 https://github.com/D-Programming-Language/dmd/commit/23bef66be596ab4541fe26a5433f8cdbd92fc4ac -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3326] $ in delegate literal causes Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=3326 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|patch, wrong-code |rejects-valid Status|RESOLVED|REOPENED CC||yebbl...@gmail.com Resolution|FIXED | --- Comment #4 from yebblies yebbl...@gmail.com 2011-07-02 15:11:16 EST --- Reopening as this hasn't been fixed, just turned into a rejects-valid -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6235] Regression(DMD 2.053) ICE on typeof(Range.init[0..$]) inside a templated struct/class
http://d.puremagic.com/issues/show_bug.cgi?id=6235 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2011-07-02 15:16:36 EST --- Using $ seems to be adding the declaration to the struct as a field. Is there any reason $ is always a variable, not just re-written as exp[... $ ... ] = exp[... exp.length ...] ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6239] New: HTOD: Add support for converting opaque C types to D
http://d.puremagic.com/issues/show_bug.cgi?id=6239 Summary: HTOD: Add support for converting opaque C types to D Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: htod AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 22:24:57 PDT --- E.g.: typedef struct _cairo_device cairo_device_t; htod translates this incorrectly to: alias _cairo_device cairo_device_t; The closest D idiom to this is: typedef void cairo_device_t; Or if typedef is ultimately killed maybe alias would work: alias void cairo_device_t; There's a ton of this stuff in C header files. :/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3326] $ in delegate literal causes Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=3326 yebblies yebbl...@gmail.com changed: What|Removed |Added Priority|P2 |P4 Severity|major |minor -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6239] HTOD: Add support for converting opaque C types to D
http://d.puremagic.com/issues/show_bug.cgi?id=6239 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 22:27:52 PDT --- For what it's worth this helps for us porting monkeys: regex: alias \w+ replace with: typedef void But you have to do this manually.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6239] HTOD: Add support for converting opaque C types to D
http://d.puremagic.com/issues/show_bug.cgi?id=6239 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01 22:33:59 PDT --- Well crap that's not good, it needs to be: typedef void cairo_device_t; typedef void _cairo_device; Stupid C APIs! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
