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

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.

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.

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!

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.

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.

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

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.

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

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