On 2012-11-28 14:07, tn wrote:

> What distinguishes manifest constants from literals? Aren't manifest
> constants just literal aliases? That is, if the following did work
>
> alias Y = 11;
>
> wouldn't that be exactly same as
>
> enum Y = 11;
>
> Perhaps using "alias" instead of "enum" would make the meaning clearer?

That doesn't sound too bad :)

-- 
/Jacob Carlborg

On 28 November 2012 15:07, tn <no@email.com> wrote:

> On Tuesday, 27 November 2012 at 21:16:41 UTC, Walter Bright wrote:
>
>> On 11/27/2012 9:51 PM, Manu wrote:
>>
>>> There's another you missed:
>>> enum X = 10;
>>> I would have imagined this would be semantically identical to E.A/E.B,
>>> but the compiler seemed to view this as distinct in my experiments.
>>>
>>
>> Those are not enums, they are manifest constants. What distinguishes a manifest constant from, say:
>>
>>     const Y = 11;
>>
>> is that no storage is allocated for X, and X's address cannot be taken.
>>
>
> What distinguishes manifest constants from literals? Aren't manifest constants just literal aliases? That is, if the following did work
>
> alias Y = 11;
>
> wouldn't that be exactly same as
>
> enum Y = 11;
>
> Perhaps using "alias" instead of "enum" would make the meaning clearer?
>

Interesting concept, but as far as the docs suggest, it's like this:
(In fear of dragging a conversation in a bug report to the NG (probably
more appropriate here)...)

enum E { X = 10 }  // enum definition
enum    { X = 10 }  // anonymous enum
enum      X = 10;   // sugar for anon enums with a single value

This is how it's documented, and it makes perfect sense to me. I like it.
In fact, I found this concept super-endearing when I initially started
using D a lot over C++.
All X's above should be identical (albeit the first has a named scope),
they're all enum values.

E is the type here, it's the only thing that an instance may be created of. X, equally in all cases, is just a constant value. I'm not sure how the language syntax distinguishes it from a literal (I'm not sure why it would have to), but it does seem the compiler distinguishes each of these X's from each other in some cases.

On 11/28/2012 02:07 PM, tn wrote:
> On Tuesday, 27 November 2012 at 21:16:41 UTC, Walter Bright wrote:
>> On 11/27/2012 9:51 PM, Manu wrote:
>>> There's another you missed:
>>> enum X = 10;
>>> I would have imagined this would be semantically identical to E.A/E.B,
>>> but the compiler seemed to view this as distinct in my experiments.
>>
>> Those are not enums, they are manifest constants. What distinguishes a
>> manifest constant from, say:
>>
>>     const Y = 11;
>>
>> is that no storage is allocated for X, and X's address cannot be taken.
>
> What distinguishes manifest constants from literals? Aren't manifest
> constants just literal aliases? That is, if the following did work
>
> alias Y = 11;
>
> wouldn't that be exactly same as
>
> enum Y = 11;
>
> Perhaps using "alias" instead of "enum" would make the meaning clearer?
>

It would not be the same thing.

immutable int i = 11;

alias Y = i; // symbol alias
enum  Z = i; // literal constant

> It would not be the same thing.
>
> immutable int i = 11;
>
> alias Y = i; // symbol alias
> enum  Z = i; // literal constant

It would work if some new way to force something to be evaluated at compile time would be added, like this:

alias Y = i; // symbol alias
alias Z = compiletime(i); // literal constant

On 11/29/2012 1:47 AM, jerro wrote:
> It would work if some new way to force something to be evaluated at
> compile time would be added, like this:
>
> alias Y = i; // symbol alias
> alias Z = compiletime(i); // literal constant

or:

   enum Z = i;  // evaluated at compile time

<g>

On Thursday, 29 November 2012 at 02:10:11 UTC, Walter Bright wrote:
> On 11/29/2012 1:47 AM, jerro wrote:
>> It would work if some new way to force something to be evaluated at
>> compile time would be added, like this:
>>
>> alias Y = i; // symbol alias
>> alias Z = compiletime(i); // literal constant
>
> or:
>
>    enum Z = i;  // evaluated at compile time
>
> <g>

Yeah, I know this does the job. I wasn't seriously proposing that we get rid of this usage of enum and define a new construct.

On 11/29/12, Walter Bright <newshound2@digitalmars.com> wrote:
> or:
>
>     enum Z = i;  // evaluated at compile time
>
> <g>

Walter how come there's commented out TOKmanifest sprinkled around the codebase? :)

On 29 November 2012 14:39, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 11/29/12, Walter Bright <newshound2@digitalmars.com> wrote:
> > or:
> >
> >     enum Z = i;  // evaluated at compile time
> >
> > <g>
>
> Walter how come there's commented out TOKmanifest sprinkled around the codebase? :)
>

He explained this somewhere else. It's because he started implementing the feature using that keyword, but then Andrei lobbied for it to be rolled into the enum concept and won the argument.