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