Allocators
David Nadlinger
code at klickverbot.at
Fri Aug 23 15:57:17 PDT 2013
On Friday, 23 August 2013 at 20:42:20 UTC, H. S. Teoh wrote:
> On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
>> On 08/23/2013 07:27 PM, Peter Alexander wrote:
>> > […]
>> >There's quite a few unresolved issues!
>>
>> Add compile-time reflection.
>
> I thought __traits solved that problem? In an ugly way,
> perhaps, but is
> there something that can't be solved with __traits?
The problem is that the language does not define how to deal with
"forward references". At all.
There are lots of cases where this matters in practice, for
example when using the information obtained by
__traits(allMembers, T) to add a new member to T (e.g. in a
serialization library). But the canonical example probably is
simply:
–––
static if (!is(typeof(b))) enum a = 0;
static if (!is(typeof(a))) enum b = 0;
// What is defined? a? b? both? Or is this illegal code?
–––
Right now, DMD is rather liberal in what it accepts, but what
exactly is legal is not clear, and evaluation order is completely
unspecified. This is a huge problem, as you end up writing a
piece of code and seeing that it compiles fine and behaves as you
would intuitively expect, assume that it is legal, only to have
the compiler choke on it or behave differently when the next
release comes out.
David
More information about the Digitalmars-d
mailing list