Robert Fraser wrote:
> mandel wrote:
>> On Thu, 06 Dec 2007 21:07:18 -0800, Walter Bright wrote:
>>
>>> David Gileadi wrote:
>>>> FWIW, alias makes the most sense to me out of the current crop of
>>>> suggestions.  To me it says that wherever I see the alias, it will be
>>>> replaced with whatever value the alias is for.  That seems to describe
>>>> manifest constants exactly.
>>> Since there's already:
>>>
>>>     alias X Y;
>>>
>>> it would seem confusing to add:
>>>
>>>     alias Y = X;
>>
>> I know it was asked before for sure,
>> but could someone point out why not just use:
>>
>> alias Y 42;
>> alias Z "abc";
>> alias X [1,2,3];
> 
> No type safety.

And the above is also backwards from current alias syntax.  The newly defined thing goes on the right, not the left.

--bb

On Fri, 07 Dec 2007 15:28:19 +0900, Bill Baxter wrote:

> Robert Fraser wrote:
>>> alias Y 42;
>>> alias Z "abc";
>>> alias X [1,2,3];
> 
> And the above is also backwards from current alias syntax.  The newly defined thing goes on the right, not the left.
> 
> --bb

oops, that wasn't intended. :)

On Dec 7, 2007 2:36 AM, sambeau <please-dont-spam-sambeau@mac.com> wrote:
> This all makes sense as an implementation, but not as a language design.
> You need to step back and look at the word 'enum' and ask yourself does it make sense?
>
> Surely, if you are proposing to change the use of 'enum' in this significant way you should change it's name. Otherwise everyone will be confused.
>
> Def, let, constants, defines,  ... , etc
>
> They all have two advantages
> 1) they sound like what they do
> 2) they aren't a reuse of something that already does something

That makes sense.

From a purely /conceptual/ point of view, "true" enums shouldn't have any numerical value at all - just a successor/predecessor relationship. That is, one can imagine (in a different language)

     enum Month { January, February, March, April, May, June, July,
August, September, October, November, December };

     Month m = Month.February;
     Month n = m.successor();
     if (n > m) { /*...*/ }

without ever exposing the implementation, or the internally stored value, which now matters only to the compiler.

However...

C did not adopt that model. Instead, C mandated that enums be implemented as an int, and C++ copied C. D then copied C/C++, but with the added feature that you get to specify the underlying type. So now we've got what we've got, and either we stick with it (...in which case I see no harm in either (a) allowing underlying types to be non-integer, or (b) treating the braces as optional...), or we rethink and start again.

We /could/ rethink and start again. We could define a new reserved word (I'm going to use "meta", just for argument's sake) which means "available at compile time". It could replace all current uses of "const" and "static" for that purpose ("static if", CTFE, etc.). That being done, one could then write

    meta int x = 3;

or just

    meta x = 3;

with type-deduction, to get a compile-time constant, and consistent keyword usage. "enum" could then be retooled to act more like a "true" enum should. Actually, I'd quite like that option. The problem is, it's probably too great a breaking change. If it only broke D2 code, no one would complain, but this would break D1 code as well. So, with that bourne in mind, Walter's solution really isn't bad.

Of all the suggestions so far, my favourite is actually the one suggested by Paul Anderson: final.

    final x = 3;

with type deduction, or

    final int x = 3;

without. When grouped:

    final
    {
        version = 3.1;
        author = "Janice";
    }

in all cases, we are declaring compile-time constants which occupy zero storage space at runtime - exactly what Walter is suggesting using "enum" for right now. After all, "final" is already a reserved word, so it's not like we'd be adding a new one.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fjake2$cid$2@digitalmars.com...
> David Gileadi wrote:
>> FWIW, alias makes the most sense to me out of the current crop of suggestions.  To me it says that wherever I see the alias, it will be replaced with whatever value the alias is for.  That seems to describe manifest constants exactly.
>
> Since there's already:
>
> alias X Y;
>
> it would seem confusing to add:
>
> alias Y = X;

I would prefer the syntax alias X = Y even for types.  To me it's more explicit and consistent with the rest of the language.

Walter Bright, el  6 de diciembre a las 16:51 me escribiste:
> Bill Baxter wrote:
> >Enum is short for 'unumeration'.  But manifest constants aren't enumerating anything.  It makes no sense.
> 
> Because we already use enums to declare constant values.
> 
> enum { x = 3 }

That's the worst reason ever! There are so many things we already use that sucks...

As has been already said, we use enum to declare constants because is the
only (ugly) way.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO...
	-- Crónica TV

On 12/7/07, Leandro Lucarella <llucax@gmail.com> wrote:
> That's the worst reason ever! There are so many things we already use that sucks...

Yep, I agree with everyone. Especially with the above comment. I will certainly /stop/ writing enum { x=3 } if a more intuitive way comes along.

So there you have it, Walter: Unanimous support on this newsgroup (...is that unprecedented?...) for NOT using enum as a storage class to define compile-time constants.

We all seem to be cool with the concept, just not with the word "enum". My fave is "final", but I'd be happy with any of the other alternatives that have been suggested so far.

Janice Caron wrote:
> On 12/7/07, Leandro Lucarella <llucax@gmail.com> wrote:
>> That's the worst reason ever! There are so many things we already use that
>> sucks...
> 
> Yep, I agree with everyone. Especially with the above comment. I will
> certainly /stop/ writing enum { x=3 } if a more intuitive way comes
> along.
> 
> So there you have it, Walter: Unanimous support on this newsgroup
> (...is that unprecedented?...) for NOT using enum as a storage class
> to define compile-time constants.
> 
> We all seem to be cool with the concept, just not with the word
> "enum". My fave is "final", but I'd be happy with any of the other
> alternatives that have been suggested so far.

Agreed.  I really don't see why you wouldn't use final.  It seems perfect.  Walter just declared there would be no more final, so it's suddenly a keyword without much to do.  It's previous meaning as a head const storage class puts it in the right syntax category already.  So what's wrong with it?

--bb

Janice Caron wrote:
> On 12/7/07, Leandro Lucarella <llucax@gmail.com> wrote:
>> That's the worst reason ever! There are so many things we already use that
>> sucks...
> 
> Yep, I agree with everyone. Especially with the above comment. I will
> certainly /stop/ writing enum { x=3 } if a more intuitive way comes
> along.
> 
> So there you have it, Walter: Unanimous support on this newsgroup
> (...is that unprecedented?...) for NOT using enum as a storage class
> to define compile-time constants.

The objections are not quite unanimous. I don't see a problem with it.

I do, however, have a problem with using 'final'. It just doesn't have any indication of being constant in my mind, since I've used Java and been able to assign to final variables time out of mind. Using enum has the benefit that nobody has ever been able to assign to an enum value.

Also, enum has the benefit of allowing groupings of constants. Potentially, at least, and certainly if you allow for casts, though that's cheating and ugly.

Bill Baxter wrote:
> Agreed.  I really don't see why you wouldn't use final.  It seems perfect.  Walter just declared there would be no more final, so it's suddenly a keyword without much to do.  It's previous meaning as a head const storage class puts it in the right syntax category already.  So what's wrong with it?
> 
> --bb

class X
{
    final
    {
        void foo() { } // Method cannot be overriden in a subclass
        int x = 5;     // Manifest constant
    }
}