Sean Kelly wrote:
> The weird thing for me is that this will allow individual enums of any type but grouped enums of only numeric types.

The following will work:

enum
{
    x = 3,   // x is int
    y = 4L,  // y is long
}

The idea is that for anonymous enums, there is no type for the enumeration as a whole. Therefore, each member of the enumeration can have a different type.

Sean Kelly wrote:
> err... make that unnamed and named.  One could argue that support for unnamed enums is simply for ease of porting from C rather than because it's a feature that really makes sense in a new language.  So making it even more entrenched is undesirable.  But we need the feature and if "enum" is it then...

Right. Anonymous enums are already conventionally used not to declare enums, but a bunch of (not necessarily related) manifest constants. In fact, in C++ we see:

template<> class factorial<1>
{
  public:
    enum { result = 1 };
};

where anonymous enums are clearly used to declare manifest constants.

Jérôme M. Berger wrote:
>>>     BTW, I think it was Janice who suggested that the compiler should
>>> know whether a constant needs to be manifest or not (depending on
>>> whether its address is taken somewhere). This would remove the need
>>> for a way to distinguish manifest constants explicitly. Any thoughts
>>> on that?
>> The reason this won't work is because:
>>     const int x = 3;
>> will type x as const(int), not int. There needs to be a way to declare a
>> constant of type int.
> 
> 	Er, why? Taking "&x" should return a "const (int)*" and using "x"
> directly should always work so long as you don't modify it.

This is where we start to see a problem if we don't type const(int) differently from int - we no longer have a straightforward rule of what the type of &x is. This may not seem consequential in trivial cases, but when you start having more complex generic code, things can get maddening. C++ tries to have it both ways, leading to startling complexity in the language definition, and a lot of intractable problems cropping up in metaprogramming.

> Are you
> telling us that the following code will fail:
> 
> void func (int param)
> {
> }
> 
> const int x = 42;
> int y = x;              // <= This should work
> func (x);               // <= This should work too
> 
> 	Or is there something I'm missing here?

These will both still work.

Janice Caron wrote:
> y is a /copy/ of x, and clearly it should be possible to make a copy
> of a const thing and have the copy be mutable.

That doesn't work for structs or classes.


> Head constness needs to
> be dropped here, exactly as it is dropped in template distinction in
> D2.008 (t!(int) is the same thing as t!(const(int)) unless special
> syntax is used).

The problem with head const is that to make the concept work, you also need the concept of tail const, and you also need to be able to separately manipulate head & tail const. That's how D's first cut at const worked, and it was a disaster.

Just for fun, how would we define a tail const member function?


> I don't see why any of this isn't possible. Maybe that's because I'm
> dumb and I'm missing something obvious, but I'm baffled as to what it
> is. And if I /haven't/ missed anything, then we don't need a new
> keyword /at all/ - be it enum, manifest, or anything else.

Believe me, we've been down this road for a year, trying all kinds of things. It doesn't work. We can get tantalizingly close to closing the circle, but cannot quite get there.

Steven Schveighoffer wrote:
>> As opposed to a minor extension to enums.
> 
> Um... this is not minor :)  This is a complete redefinition of what enum means.

enum is already used to declare arbitrary constants *that do not have an enum type* in C, C++, and D.

Lars Ivar Igesund wrote:
> Walter Bright wrote:
> 
>> Jérôme M. Berger wrote:
>>> :(
>> Yeah, I figure I'll get fricasseed over that one.
> 
> And rightfully so. This is one of the worse decisions among the bad ones in
> the D history.
> 
>> argument is that we already have 3 ways to declare a constant, adding a
>> fourth gets very difficult to justify. As opposed to a minor extension
>> to enums.
> 
> Not good enough.
> 

It'll do.  I'd say it's bad, but not that bad (I think "manifest" looked better, personally -- almost pays to go back in time and start adopting the ideas that worked several decades ago... if they indeed did work).

Like everything in D, it's one of:

(1) we eventually get used to it
(2) it eventually gets rejected and deprecated by the designer(s)
(3) or d gets abandoned. :-P

This is only a D 2.0 feature, afterall. It doesn't touch v 1.0.

I still think "foreach_reverse" was among the worst... but I guess everybody has a pet peeve.

If we need to sacrifice "enum" for the sake of a better "const" design, maybe it's worth it... but this "new" design better be good. :D

-JJR

Bill Baxter Wrote:

> Timestamp:
>      12/27/07 20:47:21 (5 hours ago)
> Author:
>      walter
> Message:
> 
>      manifest => enum
> http://www.dsource.org/projects/phobos/changeset/536
> 
> --bb

My only concern with enum is, will people use it?

In C++, using enum to define integral constants is actually the closest match to a #DEFINE. However most people use "const int", I guess either because the syntax is more convenient, it's easier to remember or because they don't know any better.

Walter Bright wrote:
> The idea is that for anonymous enums, there is no type for the enumeration as a whole. Therefore, each member of the enumeration can have a different type.

... so annonymous enums have no type for the enumeration as a whole, but named enums will?  Can named enums have a type other than int?

Walter Bright wrote:
> Steven Schveighoffer wrote:
>>> As opposed to a minor extension to enums.
>>
>> Um... this is not minor :)  This is a complete redefinition of what enum means.
> 
> enum is already used to declare arbitrary constants *that do not have an enum type* in C, C++, and D.


And, several times this argument has been rebuffed:

The reason people do this in D is usually under duress because of problems using "const".  It wasn't done because it was a preferred way nor because "enum" was something that clearly indicated its purpose.

Laying claim to this argument as a reasonable promotion of "enum" is not the best approach to proving to the D group that "enum" was an optimal choice.

Like I said, it will work. But you probably already know that it will be accepted quite begrudgingly.

Just wanted to point that out again. :)

-JJR

"Walter Bright" wrote
> Steven Schveighoffer wrote:
>>> As opposed to a minor extension to enums.
>>
>> Um... this is not minor :)  This is a complete redefinition of what enum means.
>
> enum is already used to declare arbitrary constants *that do not have an enum type* in C, C++, and D.

The implementation does not follow the semantics.  An enum is still conceptually a group of related definitions that have the same type (i.e. enumeration).  You are proposing to redefine this as a group of unrelated definitions that can have different types.  Yes, people use enum to define constants in code, but they are usually all related, even though they don't have to be, and they are all of the same type because conceptually, *an enumeration is a collection of like-type values that can be assigned to a variable of the same type*.  I like the way this is enforced today.

This is going to confuse the hell out of all newcomers, and I think there are very few people who use D that actually think this is a good idea (myself included).  There are much better ways to solve this problem than destroying the traditional meaning of enum.

-Steve