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