www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - enum abuse

reply "Mike" <none none.com> writes:
I recently saw the following line of code:

enum size = __traits(classInstanceSize, Foo);

Why "enum"?  Is this the equivalent of "immutable auto" or 
something?

Mike
Feb 28 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:
 I recently saw the following line of code:

 enum size = __traits(classInstanceSize, Foo);

 Why "enum"?  Is this the equivalent of "immutable auto" or 
 something?

 Mike
enum creates compile-time placement constant. It does not create any symbol in resulting binary. Value of such enum gets pasted straight into the context when used. Most similar thing in C terms would have been `#define size __traits(classInstanceSize, Foo)`, alas from preprocessor issues not present in D :) It is idiomatic D way to force compile-time evaluation of expression.
Feb 28 2014
parent reply "Mike" <none none.com> writes:
On Friday, 28 February 2014 at 11:47:35 UTC, Dicebot wrote:
 On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:
 I recently saw the following line of code:

 enum size = __traits(classInstanceSize, Foo);

 Why "enum"?  Is this the equivalent of "immutable auto" or 
 something?

 Mike
enum creates compile-time placement constant. It does not create any symbol in resulting binary. Value of such enum gets pasted straight into the context when used. Most similar thing in C terms would have been `#define size __traits(classInstanceSize, Foo)`, alas from preprocessor issues not present in D :) It is idiomatic D way to force compile-time evaluation of expression.
Damn good explanation. I think I'll do a pull for this in the docs. Thank you!
Feb 28 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Friday, 28 February 2014 at 12:12:34 UTC, Mike wrote:
 Damn good explanation.  I think I'll do a pull for this in the 
 docs.  Thank you!
It's mentioned here right at the bottom http://dlang.org/enum.html which could do with fleshing out a bit.
Feb 28 2014
parent "Mike" <none none.com> writes:
On Friday, 28 February 2014 at 16:32:32 UTC, Gary Willoughby 
wrote:
 On Friday, 28 February 2014 at 12:12:34 UTC, Mike wrote:
 Damn good explanation.  I think I'll do a pull for this in the 
 docs.  Thank you!
It's mentioned here right at the bottom http://dlang.org/enum.html which could do with fleshing out a bit.
I read that before posting my question. It didn't help my understanding. That's why I think I'll add Dicebot's explanation, as it is far better.
Feb 28 2014
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:
 I recently saw the following line of code:

 enum size = __traits(classInstanceSize, Foo);

 Why "enum"?  Is this the equivalent of "immutable auto" or 
 something?
A "const" or "immutable" declaration would declare a constant variable - meaning, unless it is optimized out at a later point, it will end up in the data segment and have its own address. An enum declares a manifest constant - it exists only in the memory of the compiler. Manifest constants make sense when doing metaprogramming. Constant/immutable declarations make sense for values that will be used in multiple places by code at runtime.
Feb 28 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Friday, 28 February 2014 at 11:47:45 UTC, Vladimir Panteleev 
wrote:

 A "const" or "immutable" declaration would declare a constant 
 variable - meaning, unless it is optimized out at a later 
 point, it will end up in the data segment and have its own 
 address. An enum declares a manifest constant - it exists only 
 in the memory of the compiler. Manifest constants make sense 
 when doing metaprogramming. Constant/immutable declarations 
 make sense for values that will be used in multiple places by 
 code at runtime.
I'm with Mike - thanks Vlad, that makes it perfectly clear. I just wonder slightly why a language that prides itself so on its metaprogramming capabilities does not have a keyword that makes it obvious Think of an abbreviation for compile-time-constant. But yes, thanks. BTW, why does an immutable integer type need to have an address? Steve
Feb 28 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 18:21:39 UTC, Steve Teale wrote:
 BTW, why does an immutable integer type need to have an address?

 Steve
So that you can pass it to function `void foo(immutable(int)* arg)`. It is just a normal variable after all, only immutable.
Feb 28 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 28 Feb 2014 13:21:39 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:

 I just wonder slightly why a language that prides itself so on its  
 metaprogramming capabilities does not have a keyword that makes it  
 obvious
For a *VERY* short time (I think one version perhaps), we had the 'manifest' keyword which was supposed to mean manifest constant. It was removed, Andrei was a very stanch supporter of enum being the manifest constant keyword. This comment in an early debate about what became the inout feature is pretty explanatory: https://d.puremagic.com/issues/show_bug.cgi?id=1961#c3 "And enum... you'll have to yank that out from my dead cold hands. Extending enum instead of adding yet another way of defining symbolic constants is The Right Thing to do. I am sure people would have realized how ridiculous the whole "manifest" thing is if we first proposed it. We just can't define one more way for each kind of snow there is." -Steve
Feb 28 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 28 February 2014 at 19:09:06 UTC, Steven Schveighoffer
wrote:
 For a *VERY* short time (I think one version perhaps), we had 
 the 'manifest' keyword which was supposed to mean manifest 
 constant.

 It was removed, Andrei was a very stanch supporter of enum 
 being the manifest constant keyword.  This comment in an early 
 debate about what became the inout feature is pretty 
 explanatory: 
 https://d.puremagic.com/issues/show_bug.cgi?id=1961#c3

 "And enum... you'll have to yank that out from my dead cold 
 hands. Extending
 enum instead of adding yet another way of defining symbolic 
 constants is The
 Right Thing to do. I am sure people would have realized how 
 ridiculous the
 whole "manifest" thing is if we first proposed it. We just 
 can't define one
 more way for each kind of snow there is."

 -Steve
Hmm, I didn't know that. Interesting. I think this was a mistake on Andrei's part, though. The concept of enumerations doesn't have anything to do with evaluating an expression at compile time other than how it's implemented in D and C++, so overloading the keyword to mean "evaluate this expression at compile time" does not seem like a good choice.
Feb 28 2014
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 1 March 2014 at 05:39:24 UTC, Meta wrote:
 Hmm, I didn't know that. Interesting. I think this was a mistake
 on Andrei's part, though. The concept of enumerations doesn't
 have anything to do with evaluating an expression at compile 
 time
It doesn't. enum x = expression; is the same as enum { x = expression } and minding this trivial rewrite, it generally acts in exactly the same way as C++ and other languages (plus D's CTFE capabilities, naturally). That the compiler has to fully evaluate the expression, CTFE included, to calculate the value of x, is an obvious consequence of enum semantics.
Feb 28 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 01 Mar 2014 00:39:23 -0500, Meta <jared771 gmail.com> wrote:

 On Friday, 28 February 2014 at 19:09:06 UTC, Steven Schveighoffer
 wrote:
 For a *VERY* short time (I think one version perhaps), we had the  
 'manifest' keyword which was supposed to mean manifest constant.

 It was removed, Andrei was a very stanch supporter of enum being the  
 manifest constant keyword.  This comment in an early debate about what  
 became the inout feature is pretty explanatory:  
 https://d.puremagic.com/issues/show_bug.cgi?id=1961#c3

 "And enum... you'll have to yank that out from my dead cold hands.  
 Extending
 enum instead of adding yet another way of defining symbolic constants  
 is The
 Right Thing to do. I am sure people would have realized how ridiculous  
 the
 whole "manifest" thing is if we first proposed it. We just can't define  
 one
 more way for each kind of snow there is."

 -Steve
Hmm, I didn't know that. Interesting. I think this was a mistake on Andrei's part, though. The concept of enumerations doesn't have anything to do with evaluating an expression at compile time other than how it's implemented in D and C++, so overloading the keyword to mean "evaluate this expression at compile time" does not seem like a good choice.
I think it's not so much that enum doesn't always mean "enumeration" in D, it doesn't in C or C++ either. It can be used to define bitfields, whatever. The point I think Andrei was trying to make is that enum in C and C++ does what we want, we just need to extend the types it works with. To change the name of enum would be catastrophic for existing D and C code, and to create a new name for something so totally similar would be bikeshedding. -Steve
Mar 02 2014
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 28 February 2014 at 18:21:39 UTC, Steve Teale wrote:
 On Friday, 28 February 2014 at 11:47:45 UTC, Vladimir Panteleev 
 wrote:

 A "const" or "immutable" declaration would declare a constant 
 variable - meaning, unless it is optimized out at a later 
 point, it will end up in the data segment and have its own 
 address. An enum declares a manifest constant - it exists only 
 in the memory of the compiler. Manifest constants make sense 
 when doing metaprogramming. Constant/immutable declarations 
 make sense for values that will be used in multiple places by 
 code at runtime.
I'm with Mike - thanks Vlad, that makes it perfectly clear. I just wonder slightly why a language that prides itself so on its metaprogramming capabilities does not have a keyword that makes it obvious
D has many of those. Would you think, that inout is a wild modifier which transfers to const or none-const? Or that 'in' is short for 'const scope'? That's because Walter and Andrei won't like to add more keywords and reuse old ones from D1 times. It's not that obvious but that's D. ;)
Feb 28 2014