• guslay <guslay gmail.com> Dec 11 2007
• Sean Kelly <sean f4.ca> Dec 11 2007
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Dec 11 2007
• "Steven Schveighoffer" <schveiguy yahoo.com> Dec 11 2007
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Dec 11 2007
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Dec 11 2007
• "Steven Schveighoffer" <schveiguy yahoo.com> Dec 11 2007
• "Janice Caron" <caron800 googlemail.com> Dec 11 2007
• "Janice Caron" <caron800 googlemail.com> Dec 11 2007

guslay <guslay gmail.com> writes:

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?

Sean Kelly <sean f4.ca> writes:

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?


Anything that can be represented as a compile-time constant, I believe. 
  And that includes structs.


Sean

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"guslay" <guslay gmail.com> wrote in message 
news:fjmhgg$tv2$1 digitalmars.com...
 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. 

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

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

I like the pure for manifest constants idea.  However, it implies that only 
pure methods could be called on a struct that is a manifest constant, which 
seems too limited to me.  If structs are allowed as manifest constants, then 
I don't think pure is a good keyword for it (though it's better than enum).

-Steve 

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Steven Schveighoffer wrote:
 "Jarrett Billingsley" wrote
 "guslay" wrote
 Don Clugston Wrote:

 enum SomeEnormousStruct a = SomeFunction(AnotherEnormousStruct(x, 
 "abc"));


 time strings and primitives. Is it also supposed to work with structs?


 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.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.310.1197398288.2338.digitalmars-d puremagic.com...
 On 12/11/07, Frits van Bommel <fvbommel remwovexcapss.nl> wrote:
 So opAdd & friends aren't CTFE'd? That seems like a silly omission, and
 should be easy enough to fix.


 I figure "static" within struct declaration scope means "has no this
 pointer". Only at global scope does it mean CTFE.

 I guess "static" was a bad choice of keyword for CTFE!

 My personal choice of keyword for CTFE would be /none at all/. Why
 would you need one? Let the compiler decide! If the function is
 /called/ at compile time, then that should be enough to declare it as
 CTFE.


Where did you get this idea?  You don't need to declare a function in any 
special way, at global scope or in structs, to get it to work with CTFE.  If 
a function _can_ be called at compile time, it will be.  Otherwise, it will 
defer the call to runtime.  The same function can be evaluated at compile 
time and at runtime. 

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Frits van Bommel" wrote in message
 Steven Schveighoffer wrote:
 "Jarrett Billingsley" wrote
 "guslay" wrote
 Don Clugston Wrote:

 enum SomeEnormousStruct a = SomeFunction(AnotherEnormousStruct(x, 
 "abc"));


 time strings and primitives. Is it also supposed to work with structs?


 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 

"Janice Caron" <caron800 googlemail.com> writes:

On 12/11/07, Frits van Bommel <fvbommel remwovexcapss.nl> wrote:
 So opAdd & friends aren't CTFE'd? That seems like a silly omission, and
 should be easy enough to fix.


I figure "static" within struct declaration scope means "has no this
pointer". Only at global scope does it mean CTFE.

I guess "static" was a bad choice of keyword for CTFE!

My personal choice of keyword for CTFE would be /none at all/. Why
would you need one? Let the compiler decide! If the function is
/called/ at compile time, then that should be enough to declare it as
CTFE.

As for structs and pure, I think it works. If a struct can be used in
a pure function, and contains only pure functions, then "pure" still
seems a better word than "enum". And if it's /not/ pure, then just use
const like we have up till now, and live with the storage cost!

"Janice Caron" <caron800 googlemail.com> writes:

On 12/11/07, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 Where did you get this idea?


I don't know. Glad to hear I'm wrong!

Anyway, it turns out the rule is: "the function may not be a
non-static member, i.e. it may not have a this pointer", so maybe
that's what confused me. That does look like it rules out opAdd et al
though.