[Issue 6221] New: Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221
Summary: Should be possible to pass struct function returns by
'const ref'.
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2011-06-29 01:31:54 PDT ---
struct S6221 {
int num;
}
S6221 blah6221()
{
return S6221(1);
}
void boo6221(const ref S6221 rhs) {}
void bug6221()
{
boo6221(blah6221()); // fails; not callable with argument types S6221
}
This is a particular problem because of opCmp:
struct S
{
int num;
int opCmp(const ref S rhs) const
{
if (num rhs.num)
return -1;
else if (num rhs.num)
return 1;
return 0;
}
}
S blah() {
return S(1);
}
void bug()
{
bool b1 = blah() S(45); // OK
bool b2 = S(45) blah(); // fails
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4423] [CTFE] TDPL enums of struct types
http://d.puremagic.com/issues/show_bug.cgi?id=4423 Don clugd...@yahoo.com.au changed: What|Removed |Added Depends on||6221 --- Comment #4 from Don clugd...@yahoo.com.au 2011-06-29 01:38:57 PDT --- This works in git master, if opCmp has signature int opCmp(S rhs)instead of int opCmp(const ref S rhs). The problem lies in enum.c, which tries to determine max and min for the enum by comparing the each element in the enum. Since they are struct literals, they aren't lvalues, so 'const ref' fails. This is an example of bug 6221. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #8 from yebblies yebbl...@gmail.com 2011-06-29 18:58:29 EST ---
I'll copy what I said in issue 3746:
Without this feature, what should happen with lazy void?
void lazyFunc(lazy void a) { a; }
void main()
{
int i;
lazyFunc(i++);
}
lazyFunc(i++) is currently re-written to something like
lazyFunc({return i++;})
This of course is broken if returning a non-void from a void function is
disallowed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #9 from Don clugd...@yahoo.com.au 2011-06-29 02:29:05 PDT ---
(In reply to comment #8)
I'll copy what I said in issue 3746:
Without this feature, what should happen with lazy void?
void lazyFunc(lazy void a) { a; }
void main()
{
int i;
lazyFunc(i++);
}
lazyFunc(i++) is currently re-written to something like
lazyFunc({return i++;})
This of course is broken if returning a non-void from a void function is
disallowed.
What's wrong with
lazyFunc( { i++; return;})
?
--
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 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Don clugd...@yahoo.com.au 2011-06-29 06:52:12 PDT --- https://github.com/D-Programming-Language/druntime/commit/1117e5f20adc14f9d147d47a757e5b20060c0ddb https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5aa -- 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 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2011-06-29 07:55:14 PDT --- I think this bug is invalid. A value-type return is an rvalue, and Andrei has made it very clear in his posts and in TDPL that rvalues cannot be bound to const ref parameters. I think his reasoning is that this ability was a mistake in C++, though I haven't gotten consistent answers as to why. However, I cannot tell you what you are supposed to do -- I had thought that auto ref was supposed to take care of this (i.e. you could bind an rvalue to an auto ref parameter), but I've gotten mixed interpretations from Andrei on how it is supposed to work. The fact that it works with opCmp in one direction is I think a relaxation of the rules, because struct returns would be near useless if you couldn't call any methods on them. I'll leave this up to Andrei or Walter to mark it invalid, in case I'm wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from yebblies yebbl...@gmail.com 2011-06-30 03:02:12 EST ---
(In reply to comment #9)
What's wrong with
lazyFunc( { i++; return;})
?
For some reason I was thinking this would skip the 'expression has no effect'
errors.
https://github.com/D-Programming-Language/dmd/pull/174
Fixing this found a bug in phobos.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2361] delete is allowed on invariant references.
http://d.puremagic.com/issues/show_bug.cgi?id=2361 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|x86 |All --- Comment #1 from yebblies yebbl...@gmail.com 2011-06-30 03:46:36 EST --- https://github.com/D-Programming-Language/dmd/pull/175 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5540] Probable bug-hiding redundancies
http://d.puremagic.com/issues/show_bug.cgi?id=5540 --- Comment #5 from bearophile_h...@eml.cc 2011-06-29 13:24:48 PDT --- See also: http://www.viva64.com/en/b/0103/ http://www.viva64.com/en/d/0090/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6149] ICE(interpret.c) Assertion failure: 'v2 v2-getValue()'
http://d.puremagic.com/issues/show_bug.cgi?id=6149 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2011-06-29 13:33:47 PDT --- I don't think I can reproduce this in the current dmd trunk. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6222] New: A problem with iota() using size_t
http://d.puremagic.com/issues/show_bug.cgi?id=6222
Summary: A problem with iota() using size_t
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-06-29 13:33:50 PDT ---
With DMD 2.053 this apparently goes in infinite loop:
import std.range;
void main() {
string s;
foreach (i; iota(0, s.length, 3)) {}
}
What I expect: the foreach loop to loop zero times instead.
See also bug 4603
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4603] array(iota(1, 0)) error
http://d.puremagic.com/issues/show_bug.cgi?id=4603 --- Comment #8 from bearophile_h...@eml.cc 2011-06-29 13:34:52 PDT --- See also bug 6222 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Crash on exit using std.stream.File.
The following piece of code seems to crash consistently on Windows (but it
seems to also affect Linux, and that's where I found it - particularly, it only
seemed to crash depending on the content of a static constructor: removing
almost any line from it removed the crash; the minimal test case was large, so
I have not included it).
import std.stream;
import std.stdio;
class X
{
Stream output;
this(Stream output)
{
this.output = output;
}
void close()
{
output.close();
}
~this()
{
close();
}
}
int main(string[] args)
{
new X(new std.stream.File(x.log, FileMode.OutNew));
return 0;
}
Adding writeln(output.isOpen); to the close() method removes the crash (and
returns true before .close() and false after .close(), as one would expect). On
the large test case for Linux, however, the crash persisted even with isOpen(),
and just touching the object crashed the program (it looked like I was
working with an already released object).
PS: Excuse me if I didn't follow all rules for reporting bugs, or if I'm
missing something obvious. But the code is pretty simple and I can't think
about any obvious cause.
[Issue 2367] Overloading error with string literals
http://d.puremagic.com/issues/show_bug.cgi?id=2367 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch Platform|x86 |All Version|unspecified |D2 OS/Version|Linux |All --- Comment #9 from yebblies yebbl...@gmail.com 2011-06-30 07:16:26 EST --- https://github.com/D-Programming-Language/dmd/pull/176 This issue also applies to 'null' literals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6223] New: Crash on exit when embeeding std.stream.File in a class.
http://d.puremagic.com/issues/show_bug.cgi?id=6223
Summary: Crash on exit when embeeding std.stream.File in a
class.
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: gamezel...@gmail.com
--- Comment #0 from gamezel...@gmail.com 2011-06-29 14:18:56 PDT ---
The following piece of code seems to crash consistently on Windows (but it
seems to also affect Linux, and that's where I found it - particularly, it only
seemed to crash depending on the content of a static constructor: removing
almost any line from it removed the crash; the minimal test case was large, so
I have not included it).
import std.stream;
import std.stdio;
class X
{
Stream output;
this(Stream output)
{
this.output = output;
}
void close()
{
output.close();
}
~this()
{
close();
}
}
int main(string[] args)
{
new X(new std.stream.File(x.log, FileMode.OutNew));
return 0;
}
Adding writeln(output.isOpen); to the close() method removes the crash (and
returns true before .close() and false after .close(), as one would expect). On
the large test case for Linux, however, the crash persisted even with isOpen(),
and just touching the object crashed the program (it looked like I was
working with an already released object).
PS: Sorry if I'm missing something obvious and this is a not a bug, but the
behaviour is odd, at least. Also, I posted a message directly to the mailing
list - I found that bugzilla.digitalmars.com was only for DMC, so I thought
that I should use the mailing list for D directory - sorry!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6224] New: Make a read-only public ownerTid property for std.concurrency
http://d.puremagic.com/issues/show_bug.cgi?id=6224
Summary: Make a read-only public ownerTid property for
std.concurrency
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-06-29
14:39:31 PDT ---
I need a way to get the Tid of the thread that spawned the current thread.
I've had this kind of bug creep into my code:
__gshared Tid mainThread;
__gshared Tid workThread;
workThreadFoo()
{
workThread.send(data); // Bug: Meant to be mainThread.send
}
mainThreadFoo()
{
mainThread = thisTid;
workThread = spawn(workThreadFoo);
}
This can be taken care of with this workaround:
workThreadFoo()
{
Tid mainThread = receiveOnly!Tid();
// workThread.send(data); // Now this can't creep in
mainThread.send(data); // correct
}
mainThreadFoo()
{
Tid workThread = spawn(workThreadFoo);
workThread.send(thisTid);
}
But it would be better if I didn't have to take this extra step and instead
used:
workThreadFoo()
{
Tid mainThread = thisTid.ownerTid; // new read-only property
mainThread.send(data); // correct
thisTid.ownerTid.send(data2); // also correct
}
mainThreadFoo()
{
Tid workThread = spawn(workThreadFoo);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3925] Missed escaping reference of a local variable
http://d.puremagic.com/issues/show_bug.cgi?id=3925
--- Comment #7 from bearophile_h...@eml.cc 2011-06-29 15:32:18 PDT ---
Two more cases of undetected escaping of reference:
int* ptr;
void foo1() {
int local;
ptr = local;
}
void foo2(int** x) {
int i;
*x = i;
}
void main() {}
See also bug 5541 and bug 1313
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6149] ICE(interpret.c) Assertion failure: 'v2 v2-getValue()'
http://d.puremagic.com/issues/show_bug.cgi?id=6149 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #2 from kenn...@gmail.com 2011-06-29 15:34:35 PDT --- (In reply to comment #1) I don't think I can reproduce this in the current dmd trunk. Apparently fixed in https://github.com/D-Programming-Language/dmd/commit/d1c75. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6149] ICE(interpret.c) Assertion failure: 'v2 v2-getValue()'
http://d.puremagic.com/issues/show_bug.cgi?id=6149 kenn...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6224] Make a read-only public ownerTid property for std.concurrency
http://d.puremagic.com/issues/show_bug.cgi?id=6224
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-06-29
16:11:36 PDT ---
I forgot I can also use spawn to send the Tid, e.g.:
void workThreadFoo(Tid mainThread)
{
}
spawn(workThreadFoo, thisTid);
It would still be nice to have a ownerTid property though, this is a feature
request. :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5540] Probable bug-hiding redundancies
http://d.puremagic.com/issues/show_bug.cgi?id=5540 --- Comment #6 from bearophile_h...@eml.cc 2011-06-29 16:56:41 PDT --- A class of bug-hiding redundancy: if (x == 10) foo1(); else if (x == 20) foo2(); else if (x == 10) // *** foo3(); Another class, two assignments to the same variable in a row: x = foo(); x = bar(); While this is OK: x = 1; x = x + 1; x = foo(x); Another class (the two branches are equal): if (x) foo(); else foo(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6225] New: Some common null test mistakes
http://d.puremagic.com/issues/show_bug.cgi?id=6225
Summary: Some common null test mistakes
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-06-29 17:03:56 PDT ---
In the following four cases of if I think it's better to receive warnings
from the compiler, because the code probably contains mistakes (this compiles
with no errors on DMD 2.053):
struct Foo {
int x;
bool foo() { return true; }
}
void main() {
Foo* p;
int* arr = (new int[5]).ptr;
if (p != null || p.x) {}
if (p == null p.foo()) {}
if (!p p.foo()) {}
if (arr == null arr[3]) {}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6227] New: Comparison of different enums
http://d.puremagic.com/issues/show_bug.cgi?id=6227
Summary: Comparison of different enums
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-06-29 17:06:51 PDT ---
I think comparisons of different enums may hide bugs (this compiles with no
errors on DMD 2.053):
enum Foo { x }
enum Bar { y }
void main() {
auto b = Foo.x == Bar.y;
}
A less visible to spot case:
enum { X }
enum { Y }
void main() {
auto b = X == Y;
}
See also bug 3999
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6226] New: Switch with impossible cases
http://d.puremagic.com/issues/show_bug.cgi?id=6226
Summary: Switch with impossible cases
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-06-29 17:05:15 PDT ---
In the following code the cases 400 and 200 can't happen, because they are
ouside the values range of char and byte. I suggest to raise a warning in such
cases (this compiles with no errors on DMD 2.053):
void main() {
char c;
switch (c) {
case 'a': break;
case 400: break;
default:
}
byte x;
switch (x) {
case 10: break;
case 200: break;
default:
}
}
See here for real world bug cases:
http://www.viva64.com/en/d/0142/
This too generates no errors, but I think this is less often a bug:
void main() {
char c;
if (c == 400) {}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #5 from Don clugd...@yahoo.com.au 2011-06-29 17:47:15 PDT --- I'm not convinced about this bug. Why do you think that struct literals should become rvalues (rather than non-modifiable lvalues)? It's a breaking change. You've mentioned opEquals, but it's much broader than that. Fairly obviously it also affects opCmp, but in fact, any function which takes a struct by const ref will currently accept a struct literal. Also, what about member functions? 'this' is passed by reference, yet you can use CTFE on member functions of struct literals. It's clearly a bug to allow a struct literal to be passed by non-const reference, but as to making them rvalues, I'm not sure. This needs confirmation from Walter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889 --- Comment #6 from Kenji Hara k.hara...@gmail.com 2011-06-29 18:11:03 PDT --- (In reply to comment #5) 'Literal is rvalue' is very important semantics for strict typed languages. A literal is not referenced from any other places, so it is _unique_ and _thread_local_. This is necessary for good resource management. (e.g. Unique!T, Scoped!T, etc.) But now, In D we cannot create rvalue struct object 'in place'. (Note: Returned rvalue from function might be moved, so it is not 'in place'.) It looks to me like a serious flaw. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6228] ICE(e2ir.c:1323, 2.053) on {auto x = (*ptr) ^^ y} with const integer types
http://d.puremagic.com/issues/show_bug.cgi?id=6228
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||patch
CC||yebbl...@gmail.com
--- Comment #1 from yebblies yebbl...@gmail.com 2011-06-30 14:07:07 EST ---
The bug is that a ^^ b can be incorrectly const folded when b is 0 and a is
integral but not an integral literal.
void main() {
int* ptr;
auto x = (*ptr) ^^ 0;
}
https://github.com/D-Programming-Language/dmd/pull/179
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3744] __traits getMember error in checking of second argument
http://d.puremagic.com/issues/show_bug.cgi?id=3744
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||yebbl...@gmail.com
Platform|x86 |All
Resolution||FIXED
OS/Version|Linux |All
--- Comment #12 from yebblies yebbl...@gmail.com 2011-06-30 14:38:26 EST ---
(In reply to comment #10)
Interestingly it still doesn't work even though allMembers returns a tuple
since r360:
4: foreach(m; __traits(allMembers, Check)){
5:if (!__traits(isVirtualFunction, __traits(getMember, Check, m))){
6:writefln(Var: s%, Type: %s, m, typeid(typeof(m)));
}
}
yields:
main.d(5): Error: 'this' is only defined in non-static member functions, not
main
main.d(5): Error: this for a needs to be type Check not type int
It actually works correctly now (dmd 2.053).
The errors in the sample above are because it's not possible to get a member
variable of from the class type, you need an instance.
The following works:
--
import std.stdio;
class Check { void foo() {} int bar() { return 0; } invariant() {} int x; }
void main()
{
Check check;
foreach(m; __traits(allMembers, Check))
{
if (!__traits(isVirtualFunction, __traits(getMember, check, m))){
writefln(Var: %s, Type: %s, m, typeid(typeof(m)));
}
}
}
--
The bug was fixed when __traits(allMembers) started returning a tuple.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6094] doesn't shortcut properly with CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=6094
Rob Jacques sandf...@jhu.edu changed:
What|Removed |Added
CC||sandf...@jhu.edu
Severity|enhancement |regression
--- Comment #8 from Rob Jacques sandf...@jhu.edu 2011-06-29 22:01:37 PDT ---
I'm pretty sure this is a regression between DMD 2.052 and DMD 2.053. I found
this 'regression' in template constraints:
if( isPointer!T isPointer!(pointerTarget!T) )
the problem is that if T is a string, then pointerTarget!T can not compile.
This wouldn't be an issue if that meant the template constraint failed
gracefully, but instead it halts compilation.
Anyways, there is the question of whether or not shortcutting is the correct
behavior.
From a performance point of view, as someone who has spent time optimizing
templates for compile times, anything that can reduce DMD's memory-usage or
compile times is a good thing.
From a practical point of view, being able to guard statements without using a
static if is great for template constraints and other short templates.
From a consistently point of view CTFE is already shortcutting everything
inside a if(!__ctfe){} block. (and probably other if(false){} blocks as well).
And we will never be able give up shortcutting if(!__ctfe){} blocks.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
