How about 'pure' for constants?

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Tue Dec 11 10:23:02 PST 2007


Steven Schveighoffer wrote:
> "Jarrett Billingsley" wrote
>> "guslay" wrote
>>> Don Clugston Wrote:
>>>
>>>> enum SomeEnormousStruct a = SomeFunction(AnotherEnormousStruct(x, 
>>>> "abc"));
>>>>
>>> I thought the enum concept (regardless of the keyword) was for compile 
>>> time strings and primitives. Is it also supposed to work with structs?
>>>
>>>
>> Why not?  If they're made of strings and primitives, it seems perfectly 
>> fine.  They're value types, after all.
> 
> What if the struct has methods?  The fact that it has methods is ok as those 
> are separate entities, but struct methods require a this pointer.  If this 
> is a manifest constant, it's possible that the struct cannot have a pointer 
> to the data.

The compiler could make a copy on the stack, and pass a pointer to that. 
It already does that for stuff like "Struct(datamembers).method()", and 
the manifest constant could be considered equal to a "struct 
constructor" call with constant parameters.
The stack copy could be elided when the method is inlined, of course. 
(Which isn't all that unlikely to happen, since struct methods can't be 
virtual)

> I think this could be averted if the 'this' portion of a struct was not 
> passed by reference, but passed by value.  Maybe there should be a way to 
> define whether 'this' is a pointer or a value?  This would also allow 
> operators to be used in constant expressions (one of the problems with using 
> a struct as a replacement for a math type).

So opAdd & friends aren't CTFE'd? That seems like a silly omission, and 
should be easy enough to fix. No need to pass 'this' by value.



More information about the Digitalmars-d mailing list