enum behaivor. another rehash of the topic

[Paulo Pinto]

Am 15.12.2013 02:16, schrieb Joseph Rice:
> While I must first Admit I'm new to D.   However; I have been a C/C++
> programmer for 15 years. I am excited about D.  One of the features I
> love is being able to access my legacy code.    But there are some cases
> were a complete re-write/re-factor to D makes sense. I've come to it
> very frustrating code that has been stable for years now needs to be
> changed because of a language quirk.  The main selling point about D is
> C/C++ is almost the same syntax,  I see potential in D to replace C/C++.
>
> I've noticed that enum behavior is dramatically different.  This is my
> opinion,  but I see this as a flaw in D.  Again let me repeat, My
> opinion.   While I understand D's approach to enum's. It is a hard pill
> to swallow for an experienced programmer.
>
> The D compiler should know the type of the enum from the symbol. You
> should not have to type the NAME.element when doing a comparison or
> assignment.   Declaring an enum FOO { one, two, three} should be the
> same as declaring a new type.   So that when you declare `FOO bar;` in
> code, assignment and comparison of `bar`  should know what bar is
> comprised of because it is of type enum FOO.   Therefore anything of
> type enum FOO can only comprise of the values 'one', 'two', or 'three'.
>
> I've prepared 3 examples, a C, C++, and Finally D.  All essentially the
> same code.  You will notice that the D version, has some vast
> differences. For example you can not define an enum and declare the
> variable all at once.   This gets me to the annoying part.  assigning
> and Comparing.
>
> jrice at Wayland:~/prj/enum_example$ gcc -o enum_c enum.c
> jrice at Wayland:~/prj/enum_example$ g++ -o enum_cpp enum.cpp
> jrice at Wayland:~/prj/enum_example$ dmd enum.d
> jrice at Wayland:~/prj/enum_example$ ./enum_c
> It's test1
> jrice at Wayland:~/prj/enum_example$ ./enum_cpp
> It's test1
> jrice at Wayland:~/prj/enum_example$ ./enum
> It's test1
> jrice at Wayland:~/prj/enum_example$ cat enum.c
> #include <stdio.h>
>
> void main() {
>      enum TEST {
>          test1=0,
>          test2
>      } test;
>
>      test = test1;
>
>      switch (test) {
>          case test1:
>              printf("It's test1\n");
>              break;
>          case test2:
>              printf("It's test2\n");
>              break;
>          default:
>          break;
>      }
> }
> jrice at Wayland:~/prj/enum_example$ cat enum.cpp
> #include <iostream>
> using namespace std;
>
> int main() {
>      enum TEST {
>          test1=0,
>          test2
>      } test;
>
>      test = test1;
>
>      switch (test) {
>          case test1:
>              cout << "It's test1" << endl;
>              break;
>          case test2:
>              cout << "It's test2" << endl;
>              break;
>          default:
>          break;
>      }
>      return 0;
> }
> jrice at Wayland:~/prj/enum_example$ cat enum.d
> import std.stdio;
>
> void main() {
>      enum TEST {
>          test1=0,
>          test2
>      };
>
>      TEST test = TEST.test1;
>
>      switch (test) {
>          case TEST.test1:
>              writeln("It's test1");
>              break;
>          case TEST.test2:
>              writeln("It's test2");
>              break;
>          default:
>          break;
>      }
> }
>
> So as you can see, D is just awkward, and it becomes tedious especially
> if you have many many many values in the enum.
>
>
> So D language Designers and maintainers:
>
> 1st
>
> I understand your reasons, it makes it un-ambiguous, becaause you know
> exactly which enum `test1` belongs too.
>
> 2nd
>
> What the heck, why do I have to type extra.  It makes porting a little
> mre frustrating, and makes me question using D in the first place.
>
> 3rd
>
> I'm Pleading to you to consider making both syntax's valid. The Old
> C/C++ way,  and the D way.  If you have too, make compiler flag.


It follows the same approach as many other modern languages, even C++ 
has them nowadays.

Obviously, the world at large has come to the conclusion that having 
enum identifiers creeping into global scope in C was not a good idea.

--
Paulo