How about 'pure' for constants?

[Steven Schveighoffer]

"Frits van Bommel" wrote in message
> 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)

Yes, you are correct.  It could do this.  It makes sense too, thanks for 
pointing it out :)

however, I'm still against pure as a keyword if structs can be manifest 
constants because it implies that the struct can only call pure methods, 
which is too limited in my opinion.

>> 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.

>From the CTFE description:

4. the function may not be a non-static member, i.e. it may not have a this 
pointer

I'm all for changing that, but I'm guessing Walter had a reason to specify 
it that way :)  If the CTFE engine just did what you said above (make a copy 
of the constant on the stack, and pass the pointer to that), I think it 
would work!

-Steve