In C we are able to write:
    enum A { a1, a2, a3 };
    int main()
    {
        enum A a;
        a = a1;
        a = a2;
        a = a3;
        return 0;
    }
Why is this prevented in D?
Doesn't anybody think it is useful? I do.

Consider Pavel's streams.
You would write "new File('file.txt', Out);"
instead of "new File('file.txt', FileMode.Out);"!

Dario wrote:
> 
> In C we are able to write:
>     enum A { a1, a2, a3 };
>     int main()
>     {
>         enum A a;
>         a = a1;
>         a = a2;
>         a = a3;
>         return 0;
>     }
> Why is this prevented in D?
> Doesn't anybody think it is useful? I do.

I think currently you have to use the long form
or define an alias:

enum A { a1, a2, a3 };

alias A.a1 a1;

int main()
{
   A a;
   a = a1;
   a = A.a2;
   a = A.a3;
   return 0;
}

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Dario" <supdar@yahoo.com> wrote in message news:bcd06e$1af0$1@digitaldaemon.com...
> In C we are able to write:
>     enum A { a1, a2, a3 };
>     int main()
>     {
>         enum A a;
>         a = a1;
>         a = a2;
>         a = a3;
>         return 0;
>     }
> Why is this prevented in D?
> Doesn't anybody think it is useful? I do.

Useful? Yes, in small programs, or those that do not use any shared/common
libraries.
Practicable? Not in the slightest. Less typing now almost always means more
typing later.

>
> Consider Pavel's streams.
> You would write "new File('file.txt', Out);"
> instead of "new File('file.txt', FileMode.Out);"!
>
>

> Useful? Yes, in small programs, or those that do not use any shared/common libraries.

> Practicable? Not in the slightest. Less typing now almost always means
more
> typing later.

Thid doesn't seem to be the case. You ALWAYS type less.
Why should this cause you type more?

For example, File.this(HANDLE, FileMode) is passed a FileMode value.
So the compiler knows where to look for identifiers like In and Out which
I pass to the constructor.

The problem is probably this:
    void func(char[] filename)
    {
        FileMode Out = In;
        File f = new File(filename, Out);
        // what is passed? local Out or FileMode.Out
    }
I think the compiler should consider this an ambiguity error.
(You can change the variable name so that it doesn't make any conflict.)

"Dario" <supdar@yahoo.com> wrote in message news:bcd06e$1af0$1@digitaldaemon.com...
> In C we are able to write:
>     enum A { a1, a2, a3 };
>     int main()
>     {
>         enum A a;
>         a = a1;
>         a = a2;
>         a = a3;
>         return 0;
>     }
> Why is this prevented in D?
> Doesn't anybody think it is useful? I do.

There are two types of enums in D, named and unnamed.

Named:

     enum A { a1, a2, a3 };
     int main()
     {
         A a;
         a = A.a1;
         a = A.a2;
         a = A.a3;
         return 0;
     }

Unnamed:

     enum { a1, a2, a3 };
     int main()
     {
         int a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }



> Consider Pavel's streams.
> You would write "new File('file.txt', Out);"
> instead of "new File('file.txt', FileMode.Out);"!

Common practice in C is to:

    enum FOO { FOObar, FOOdef };

to avoid name collisions. The aim in D is for the more sensible FOO.bar and FOO.def. You can still emulate the C version if you really want to:

     enum { a1, a2, a3 };
     alias int A;
     int main()
     {
         A a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }

Dario wrote:

> In C we are able to write:
>     enum A { a1, a2, a3 };
>     int main()
>     {
>         enum A a;
>         a = a1;
>         a = a2;
>         a = a3;
>         return 0;
>     }
> Why is this prevented in D?
> Doesn't anybody think it is useful? I do.

What you're asking for is ambiguous.  If you mean that a1 should exist
in the parent namespace, then you can do that this way:

   typedef uint A;
   enum : A { a1, a2, a3 }

If you mean that the enumeration should be identified based on context,
it's possible, but I'm agnostic.  I didn't like named enumerations when
I started either, now I use them.  This looks good for small functions,
but I get enough trouble with large functions where I can't remember
what "true" means in this argument's context.

> Consider Pavel's streams.
> You would write "new File('file.txt', Out);"
> instead of "new File('file.txt', FileMode.Out);"!

I don't like handing firmament-altering parameters to functions anyway;
"new CreateFile('file.txt')" would be nicer to me, "ReadWriteFile"
for the third variation.  Or just the ol' "rw" method.  I like that.