www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Enums can be annoyingly verbose...

reply Regan Heath <regan netwin.co.nz> writes:
I have mentioned this before, but I kinda want some more opinions on the 
matter/idea.

Currently we have to specify an enum by it's full name, this can be quite 
long and you can end up writing/copying/pasting the enum name a few times.

Surely it's possible in most cases for the compiler to determine the Enum 
name and thus it's not really required.

Example:

enum FooBarBaz : ushort
{
   THE   = 0x0001,
   QUICK = 0x0002,
   BROWN = 0x0004,
   FOX   = 0x0008,
   JUMPS = 0x0010,
   OVER  = 0x0020,
   THE   = 0x0040,
   LAZY  = 0x0080,
   DOG   = 0x0100
}

void fooBar(FooBarBaz a) {}

void main()
{
   //current method
   fooBar(FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.LAZY|FooBarBaz.DOG);

   //proposed method
   fooBar(THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG);

   //alternate method
   fooBar(with(FooBarBaz){THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG});
}

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 09 2004
next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Regan Heath" <regan netwin.co.nz> escribió en el mensaje
news:opschrxff75a2sq9 digitalmars.com
| enum FooBarBaz : ushort
| {
|    THE   = 0x0001,
|    QUICK = 0x0002,
|    BROWN = 0x0004,
|    FOX   = 0x0008,
|    JUMPS = 0x0010,
|    OVER  = 0x0020,
|    THE   = 0x0040,
|    LAZY  = 0x0080,
|    DOG   = 0x0100
| }
|

You can do it like this:

typedef ushort FooBarBaz;
enum : FooBarBaz
{ ... }

-----------------------
Carlos Santander Bernal
Aug 09 2004
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
or you can do it like this.

enum : ushort
{
   THE=0x01;
   ...
}

only problem is that you lose the enum name, which is nice to have if you
have conflicting names (but that shouldn't happen very often).
Aug 09 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley <kb3ctd2 yahoo.com> 
wrote:


 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have if you
 have conflicting names (but that shouldn't happen very often).


Thanks, I didn't realise you could have un-named enums.

However I still think there is merit in my idea, Walter how hard would it 
be to have the compiler treat this:

   fooBar(THE);

the same as

   fooBar(EnumName.THE);

given that

   void fooBar(EnumName a);

basically tells you what to expect.

?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 09 2004
parent reply Deja Augustine <deja scratch-ware.net> writes:
Regan Heath wrote:

 On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:
 

 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have if you
 have conflicting names (but that shouldn't happen very often).


 
 
 Thanks, I didn't realise you could have un-named enums.
 
 However I still think there is merit in my idea, Walter how hard would 
 it be to have the compiler treat this:
 
   fooBar(THE);
 
 the same as
 
   fooBar(EnumName.THE);
 
 given that
 
   void fooBar(EnumName a);
 
 basically tells you what to expect.
 
 ?
 
 Regan
 


The reason that it requires a fully qualified name is to prevent name 
clashes, and to make the code more clear.  What would the compiler do if 
you had:

void fooBar(ushort s);

enum Foo : ushort { one, is, the, first, number }
enum Bar : ushort { just, one, more, time }

fooBar(one); // would it be Foo.one or Bar.one?

Requiring Foo.one or Bar.one provides clearer code.  If you just want 
global constants, then use an anonymous enum, that's what it's there for.

-Deja
Aug 09 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine <deja scratch-ware.net> 
wrote:

 Regan Heath wrote:

 On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:


 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have if 
 you
 have conflicting names (but that shouldn't happen very often).



 Thanks, I didn't realise you could have un-named enums.

 However I still think there is merit in my idea, Walter how hard would 
 it be to have the compiler treat this:

   fooBar(THE);

 the same as

   fooBar(EnumName.THE);

 given that

   void fooBar(EnumName a);

 basically tells you what to expect.

 ?

 Regan


 The reason that it requires a fully qualified name is to prevent name 
 clashes, and to make the code more clear.  What would the compiler do if 
 you had:

 void fooBar(ushort s);

 enum Foo : ushort { one, is, the, first, number }
 enum Bar : ushort { just, one, more, time }

 fooBar(one); // would it be Foo.one or Bar.one?


An excellent question. The answer, this requires a fully qualified name.


 Requiring Foo.one or Bar.one provides clearer code.


I agree that in your above example the fully qualified name makes it 
clearer, but then I'm not asking to be able to use non-fully qualified 
names in situations shown by your example.

I don't believe fully qualifying makes _my_ example any clearer, nor does 
it make other similar situations any clearer.


 If you just want global constants, then use an anonymous enum, that's 
 what it's there for.


I don't want global constants specifically. I just don't want to have to 
type FooBarBaz 6 times.

I'm not suggesting abolishing fully qualified names, far from it. I'm 
simply saying in certain situations it knows what you mean without you 
having to say so. (several times)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 09 2004
parent reply Deja Augustine <deja scratch-ware.net> writes:
Regan Heath wrote:


 On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
 <deja scratch-ware.net> wrote:
 

 Regan Heath wrote:


 On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:


 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have 
 if you
 have conflicting names (but that shouldn't happen very often).




 Thanks, I didn't realise you could have un-named enums.

 However I still think there is merit in my idea, Walter how hard 
 would it be to have the compiler treat this:

   fooBar(THE);

 the same as

   fooBar(EnumName.THE);

 given that

   void fooBar(EnumName a);

 basically tells you what to expect.

 ?

 Regan


 The reason that it requires a fully qualified name is to prevent name 
 clashes, and to make the code more clear.  What would the compiler do 
 if you had:

 void fooBar(ushort s);

 enum Foo : ushort { one, is, the, first, number }
 enum Bar : ushort { just, one, more, time }

 fooBar(one); // would it be Foo.one or Bar.one?


 
 
 An excellent question. The answer, this requires a fully qualified name.
 

 Requiring Foo.one or Bar.one provides clearer code.


 
 
 I agree that in your above example the fully qualified name makes it 
 clearer, but then I'm not asking to be able to use non-fully qualified 
 names in situations shown by your example.
 
 I don't believe fully qualifying makes _my_ example any clearer, nor 
 does it make other similar situations any clearer.
 

 If you just want global constants, then use an anonymous enum, that's 
 what it's there for.


 
 
 I don't want global constants specifically. I just don't want to have to 
 type FooBarBaz 6 times.
 
 I'm not suggesting abolishing fully qualified names, far from it. I'm 
 simply saying in certain situations it knows what you mean without you 
 having to say so. (several times)
 
 Regan
 



Well, personally, I think that Walter has far far more important issues 
than reducing the amount of copy/paste you have to do because you want 
fully-qualified enums without using fully-qualified identifiers.

The option of global constants exists for you if you're that lazy that 
you can't type an additional 10 characters to use an enum value.

If you really are that lazy, just enclose the bit you want with:

with(FooBarBaz)
{
/+ all your code you don't want to use an FQI for +/
}

You've wasted more keystrokes typing up and defending this ridiculous 
request to assist lazy coding practices than you probably will use 
typing in "FooBarBaz." in your current project.

I can see no justification for coding implicit enum resolution into the 
compiler when there are several much less ambiguous options available.

-Deja
Aug 09 2004
next sibling parent Deja Augustine <deja scratch-ware.net> writes:
Deja Augustine wrote:


 Regan Heath wrote:
 

 On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
 <deja scratch-ware.net> wrote:


 Regan Heath wrote:


 On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:


 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have 
 if you
 have conflicting names (but that shouldn't happen very often).





 Thanks, I didn't realise you could have un-named enums.

 However I still think there is merit in my idea, Walter how hard 
 would it be to have the compiler treat this:

   fooBar(THE);

 the same as

   fooBar(EnumName.THE);

 given that

   void fooBar(EnumName a);

 basically tells you what to expect.

 ?

 Regan


 The reason that it requires a fully qualified name is to prevent name 
 clashes, and to make the code more clear.  What would the compiler do 
 if you had:

 void fooBar(ushort s);

 enum Foo : ushort { one, is, the, first, number }
 enum Bar : ushort { just, one, more, time }

 fooBar(one); // would it be Foo.one or Bar.one?




 An excellent question. The answer, this requires a fully qualified name.


 Requiring Foo.one or Bar.one provides clearer code.




 I agree that in your above example the fully qualified name makes it 
 clearer, but then I'm not asking to be able to use non-fully qualified 
 names in situations shown by your example.

 I don't believe fully qualifying makes _my_ example any clearer, nor 
 does it make other similar situations any clearer.


 If you just want global constants, then use an anonymous enum, that's 
 what it's there for.




 I don't want global constants specifically. I just don't want to have 
 to type FooBarBaz 6 times.

 I'm not suggesting abolishing fully qualified names, far from it. I'm 
 simply saying in certain situations it knows what you mean without you 
 having to say so. (several times)

 Regan


 
 


<snip>

 If you really are that lazy, just enclose the bit you want with:
 
 with(FooBarBaz)
 {
 /+ all your code you don't want to use an FQI for +/
 }


<snip>

I do stand corrected.  with statements only work on classes and structs.

-Deja
Aug 09 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 10 Aug 2004 00:28:55 -0500, Deja Augustine <deja scratch-ware.net> 
wrote:

 Regan Heath wrote:


 On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
 <deja scratch-ware.net> wrote:


 Regan Heath wrote:


 On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:


 or you can do it like this.

 enum : ushort
 {
    THE=0x01;
    ...
 }

 only problem is that you lose the enum name, which is nice to have 
 if you
 have conflicting names (but that shouldn't happen very often).




 Thanks, I didn't realise you could have un-named enums.

 However I still think there is merit in my idea, Walter how hard 
 would it be to have the compiler treat this:

   fooBar(THE);

 the same as

   fooBar(EnumName.THE);

 given that

   void fooBar(EnumName a);

 basically tells you what to expect.

 ?

 Regan


 The reason that it requires a fully qualified name is to prevent name 
 clashes, and to make the code more clear.  What would the compiler do 
 if you had:

 void fooBar(ushort s);

 enum Foo : ushort { one, is, the, first, number }
 enum Bar : ushort { just, one, more, time }

 fooBar(one); // would it be Foo.one or Bar.one?



 An excellent question. The answer, this requires a fully qualified name.


 Requiring Foo.one or Bar.one provides clearer code.



 I agree that in your above example the fully qualified name makes it 
 clearer, but then I'm not asking to be able to use non-fully qualified 
 names in situations shown by your example.

 I don't believe fully qualifying makes _my_ example any clearer, nor 
 does it make other similar situations any clearer.


 If you just want global constants, then use an anonymous enum, that's 
 what it's there for.



 I don't want global constants specifically. I just don't want to have 
 to type FooBarBaz 6 times.

 I'm not suggesting abolishing fully qualified names, far from it. I'm 
 simply saying in certain situations it knows what you mean without you 
 having to say so. (several times)

 Regan



 Well, personally, I think that Walter has far far more important issues 
 than reducing the amount of copy/paste you have to do


I agree completely. I am not suggesting this be done 'right now' if you 
had read my initial post you would notice I said ".. I kinda want some 
more opinions on the matter/idea."


 because you want fully-qualified enums without using fully-qualified 
 identifiers.

 The option of global constants exists for you if you're that lazy that 
 you can't type an additional 10 characters to use an enum value.

 If you really are that lazy, just enclose the bit you want with:

 with(FooBarBaz)
 {
 /+ all your code you don't want to use an FQI for +/
 }

 You've wasted more keystrokes typing up and defending this ridiculous 
 request to assist lazy coding practices than you probably will use 
 typing in "FooBarBaz." in your current project.

 I can see no justification for coding implicit enum resolution into the 
 compiler when there are several much less ambiguous options available.


Firstly my initial suggestion is not ambiguous, your example, which was 
not what I was suggesting was ambiguous. To explain, my idea:

enum FooBarBaz {
   ONE,TWO
}

fooBar(ONE);

is not any more/less ambiguous than

fooBar(FooBarBaz.ONE);

because if you're wondering what ONE is, and what it means to FooBar you 
have to lookup both the 'fooBar' function and the 'FooBarBaz' enum. In the 
case of my example, the former gives you the name of the latter.

Secondly, the point of this thread is to hear people opinions, not to 
prompt Walter into action, so, while I thank you for your opinions I take 
exception to being called "lazy" repeatedly, and for no reason except that 
you have no real argument against my idea.

Sure it's not a super important feature/idea, but it's a nice touch, one 
that so far you have given no real reasons against it, all you have said 
is:
  - that I am lazy
  - that walter has more important thing to do
  - that it is ambiguous.

to all of which I believe I have replied in a civil manner, which is more 
than I can say for you.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 10 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <opscjg92ma5a2sq9 digitalmars.com>, Regan Heath says...

On Tue, 10 Aug 2004 00:28:55 -0500, Deja Augustine <deja scratch-ware.net> 
wrote:

 I can see no justification for coding implicit enum resolution into the 
 compiler when there are several much less ambiguous options available.


Firstly my initial suggestion is not ambiguous, your example, which was 
not what I was suggesting was ambiguous. To explain, my idea:

enum FooBarBaz {
   ONE,TWO
}

fooBar(ONE);

is not any more/less ambiguous than

fooBar(FooBarBaz.ONE);

because if you're wondering what ONE is, and what it means to FooBar you 
have to lookup both the 'fooBar' function and the 'FooBarBaz' enum. In the 
case of my example, the former gives you the name of the latter.


But if the 'FooBarBaz' is omitted then the user does not know which enum to
check.  This is especially true if fooBar takes an int value and the enum is
being implicitly cast.  IMO D corrects what can be a very subtle source of bugs
in C/C++ by requiring named enums to be qualified appropriately.  I would very
much not like this to change, especially if the reason is just to save a few
keystrokes.


Sure it's not a super important feature/idea, but it's a nice touch, one 
that so far you have given no real reasons against it, all you have said 
is:
  - that I am lazy
  - that walter has more important thing to do
  - that it is ambiguous.


The only point I agree with is the one regarding ambiguity.  Consider this code:





















The above is unambiguous because there is only one defined value for RED.
However, assume that during the course of maintenance a programmer discovers
that he needs something from module b, so he imports that and for some reason
removes the line importing module a.  Everything compiles just fine because RED
is still defined, but the PaintScreen call is now operating on a completely
different value.  In more complex cases such bugs can be extremely difficult to
diagnose, especially if the affected code is something that has been left
unchanged for years.


Sean
Aug 11 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 11 Aug 2004 21:23:57 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:

 In article <opscjg92ma5a2sq9 digitalmars.com>, Regan Heath says...

 On Tue, 10 Aug 2004 00:28:55 -0500, Deja Augustine 
 <deja scratch-ware.net>
 wrote:

 I can see no justification for coding implicit enum resolution into the
 compiler when there are several much less ambiguous options available.


 Firstly my initial suggestion is not ambiguous, your example, which was
 not what I was suggesting was ambiguous. To explain, my idea:

 enum FooBarBaz {
   ONE,TWO
 }

 fooBar(ONE);

 is not any more/less ambiguous than

 fooBar(FooBarBaz.ONE);

 because if you're wondering what ONE is, and what it means to FooBar you
 have to lookup both the 'fooBar' function and the 'FooBarBaz' enum. In 
 the
 case of my example, the former gives you the name of the latter.


 But if the 'FooBarBaz' is omitted then the user does not know which enum 
 to
 check.


Yes they do.. think about how you'd go about it, first you'd look up the 
function, because what point is knowing the value of the enum if you don't 
know what's being done with it. The function includes the name of the 
enum... well... until I read your statement below I assumed it would :)


 This is especially true if fooBar takes an int value and the enum is
 being implicitly cast.


Ahh.. I didn't think of this. :)

So.. 'enum' is implicitly convertable to 'int' but 'int' is not implicitly 
convertable to 'enum', is that completely sensible do you think?

I guess I assumed as 'int' wasn't implicitly convertable to 'enum' that 
the reverse would hold true also.


I have just discovered something slightly weird...

enum Test : ubyte {
   ONE = 0x1,
   TWO = 0x2
}

void foo(Test a)
{
}

void main()
{
   foo(Test.ONE);
   foo(Test.ONE|Test.TWO);  //function foo (Test a) does not match argument 
types (int)
                            //cannot implicitly convert expression 
cast(int)(1)
                            // | cast(int)(2) of type int to Test
}

Bug? or not?


 IMO D corrects what can be a very subtle source of bugs
 in C/C++ by requiring named enums to be qualified appropriately.  I 
 would very
 much not like this to change, especially if the reason is just to save a 
 few
 keystrokes.


The reason above is the first good one I've heard against my proposal. It 
probably kills it stone dead too.


 Sure it's not a super important feature/idea, but it's a nice touch, one
 that so far you have given no real reasons against it, all you have said
 is:
  - that I am lazy
  - that walter has more important thing to do
  - that it is ambiguous.


 The only point I agree with is the one regarding ambiguity.  Consider 
 this code:





















 The above is unambiguous because there is only one defined value for RED.


I assume you're missing an 'import b'; above?


 However, assume that during the course of maintenance a programmer 
 discovers
 that he needs something from module b, so he imports that and for some 
 reason
 removes the line importing module a.  Everything compiles just fine 
 because RED
 is still defined, but the PaintScreen call is now operating on a 
 completely
 different value.  In more complex cases such bugs can be extremely 
 difficult to
 diagnose, especially if the affected code is something that has been left
 unchanged for years.


Yeah.. my assumption about the implicit conversion was the killer.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 11 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opscld1nzg5a2sq9 digitalmars.com>, Regan Heath says...


 This is especially true if fooBar takes an int value and the enum is
 being implicitly cast.


Ahh.. I didn't think of this. :)


Yes you did. Or at least, your original idea, as I now understand it, completely
covers this possibility. It works like this - assume your enum-type-detection
system is up and running, then:





This is simply a compile error, because f takes an int, and therefore "with
Qwerty" is not assumed when parsing f(ONE); Accordingly, ONE is simply an
unknown identifier. To get it to compile, you'd have either to change line 3 to
f(Qwerty.ONE); or else change line 2 to void f(Qwerty x);






I have just discovered something slightly weird...

enum Test : ubyte {
   ONE = 0x1,
   TWO = 0x2
}

void foo(Test a)
{
}

void main()
{
   foo(Test.ONE);
   foo(Test.ONE|Test.TWO);  //function foo (Test a) does not match argument 
types (int)
                            //cannot implicitly convert expression 
cast(int)(1)
                            // | cast(int)(2) of type int to Test
}

Bug? or not?


I think this is what I tried to mention in my last responce. The type of
Test.ONE is Test, but the operator | takes ints, and returns an int, so both
Test.ONE and Test.TWO are converted to int for the benefit of operator |, and
the result is syntactically an int. Since ints cannot be implicitly cast to
named enums, you have a compile error. You make it compile by doing:



I have to say, though, I'm not greatly in favor of using enums as bit masks. I
realize that (other) people do it all the time, but it seems to me that using an
enum variable to hold a numerical value for which there is no corresponding enum
name is violating (my conception of) what an enum is for. But that's just me,
and I know other people do things differently.



 IMO D corrects what can be a very subtle source of bugs
 in C/C++ by requiring named enums to be qualified appropriately.  I 
 would very
 much not like this to change, especially if the reason is just to save a 
 few
 keystrokes.


The reason above is the first good one I've heard against my proposal. It 
probably kills it stone dead too.


I've argued that it doesn't, however, /this/ might do:







The evaluation of the expression f(ONE) requires an implicit "with", which the
compiler can only get from the declaration of f() - but this requires knowing in
advance which overload of f() is going to be used. Unfortunately, overload
resolution requires knowing the types of the arguments, and so requires the
arguments to be parsed /first/. We have ourselves some circularity! The only way
out of this would be to allow "implicit withs" only on non-overloaded functions.
(Or at least, functions which are not overloaded to the point of ambiguity, but
we may be asking too much of the compiler at this point).

Arcane Jill
Aug 11 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 12 Aug 2004 06:56:43 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 In article <opscld1nzg5a2sq9 digitalmars.com>, Regan Heath says...


 This is especially true if fooBar takes an int value and the enum is
 being implicitly cast.


 Ahh.. I didn't think of this. :)


 Yes you did. Or at least, your original idea, as I now understand it, 
 completely
 covers this possibility. It works like this - assume your 
 enum-type-detection
 system is up and running, then:





 This is simply a compile error, because f takes an int, and therefore 
 "with
 Qwerty" is not assumed when parsing f(ONE); Accordingly, ONE is simply an
 unknown identifier. To get it to compile, you'd have either to change 
 line 3 to
 f(Qwerty.ONE); or else change line 2 to void f(Qwerty x);


True..


 I have just discovered something slightly weird...

 enum Test : ubyte {
   ONE = 0x1,
   TWO = 0x2
 }

 void foo(Test a)
 {
 }

 void main()
 {
   foo(Test.ONE);
   foo(Test.ONE|Test.TWO);  //function foo (Test a) does not match 
 argument
 types (int)
                            //cannot implicitly convert expression
 cast(int)(1)
                            // | cast(int)(2) of type int to Test
 }

 Bug? or not?


 I think this is what I tried to mention in my last responce.


Not quite.. as this works:

enum EnumName { A,B,C };
void foo(EnumName a);
foo(EnumName.A|EnumName.B|EnumName.C);

the problem with the above is the ": ubyte" on the enum.


 The type of
 Test.ONE is Test, but the operator | takes ints, and returns an int, so 
 both
 Test.ONE and Test.TWO are converted to int for the benefit of operator 
 |, and
 the result is syntactically an int. Since ints cannot be implicitly cast 
 to
 named enums, you have a compile error.


It appears something like this is heppening, but something else is also 
going on when the enum has no base type specified, it seems the 'int' 
produced by the | _can_ be implicitly cast back to the enum type.


 You make it compile by doing:



 I have to say, though, I'm not greatly in favor of using enums as bit 
 masks. I
 realize that (other) people do it all the time, but it seems to me that 
 using an
 enum variable to hold a numerical value for which there is no 
 corresponding enum
 name is violating (my conception of) what an enum is for.  But that's 
 just me,
 and I know other people do things differently.


So how do you define a bunch of flag (off/on) options which you are 
storing in a ubyte, uint or ulong?


 IMO D corrects what can be a very subtle source of bugs
 in C/C++ by requiring named enums to be qualified appropriately.  I
 would very
 much not like this to change, especially if the reason is just to save 
 a
 few
 keystrokes.


 The reason above is the first good one I've heard against my proposal. 
 It
 probably kills it stone dead too.


 I've argued that it doesn't, however, /this/ might do:







 The evaluation of the expression f(ONE) requires an implicit "with", 
 which the
 compiler can only get from the declaration of f() - but this requires 
 knowing in
 advance which overload of f() is going to be used. Unfortunately, 
 overload
 resolution requires knowing the types of the arguments, and so requires 
 the
 arguments to be parsed /first/. We have ourselves some circularity! The 
 only way
 out of this would be to allow "implicit withs" only on non-overloaded 
 functions.
 (Or at least, functions which are not overloaded to the point of 
 ambiguity, but
 we may be asking too much of the compiler at this point).


Yeah, that is nasty, I think in this case and any other where it is 
ambiguous you simply have to provide the enum ('A' or 'B' in the above 
example).

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 16 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opscuuezyz5a2sq9 digitalmars.com>, Regan Heath says...


 I have to say, though, I'm not greatly in favor of using enums as bit 
 masks. I
 realize that (other) people do it all the time, but it seems to me that 
 using an
 enum variable to hold a numerical value for which there is no 
 corresponding enum
 name is violating (my conception of) what an enum is for.  But that's 
 just me,
 and I know other people do things differently.


So how do you define a bunch of flag (off/on) options which you are 
storing in a ubyte, uint or ulong?


Me, personally?

Well, in C and C++, I would do this:













But of course you can't do that in D. In other langauges, I might do something
like:










although of course the code is then less typesafe. More likely, I'd just do:









(although that, of course, is not bit-packed).

In D, however, there is a brand new option, to replace C's struct bitfields,
which is this:







I've just started playing with this idea. I have no idea how efficient it
is/isn't.

Jill
Aug 16 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 17 Aug 2004 06:55:26 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 In D, however, there is a brand new option, to replace C's struct 
 bitfields,
 which is this:







 I've just started playing with this idea. I have no idea how efficient it
 is/isn't.


But of course! I simply wasn't thinking in D!

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 17 2004
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> escribió en el mensaje
news:cf99h1$160a$1 digitaldaemon.com
| or you can do it like this.
|
| enum : ushort
| {
|    THE=0x01;
|    ...
| }
|
| only problem is that you lose the enum name, which is nice to have if you
| have conflicting names (but that shouldn't happen very often).

But then he loses his FooBarBaz type.

-----------------------
Carlos Santander Bernal
Aug 11 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opschrxff75a2sq9 digitalmars.com>, Regan Heath says...


   //proposed method
   fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG);


Would that work? I mean, I can see that:



would work, since (assuming your proposed scheme) the compiler would be able to
infer the type of the fooBar parameter. But as for



I have to ask - what is the compile-time type of the expression:



My guess is that the compile-time type of even the expression:


FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.LAZY|FooBarBaz.DOG

is not actually FooBarBaz, but is in fact int. Does the | operator preserve the
type of an enum? I'm not sure that it does.

Arcane Jill
(basically in support but with one or two niggling doubts).
Aug 10 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 10 Aug 2004 11:56:06 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 In article <opschrxff75a2sq9 digitalmars.com>, Regan Heath says...


   //proposed method
   fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG);


 Would that work? I mean, I can see that:



 would work, since (assuming your proposed scheme) the compiler would be 
 able to
 infer the type of the fooBar parameter. But as for



 I have to ask - what is the compile-time type of the expression:



 My guess is that the compile-time type of even the expression:


 FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.LAZY|FooBarBaz.DOG

 is not actually FooBarBaz, but is in fact int. Does the | operator 
 preserve the
 type of an enum? I'm not sure that it does.


Good question.. I think Walter is the only one who can really answer it, 
however, my tests show that you cannot pass an 'int' to a function 
expecting a 'FooBarBaz', but you can pass something like 
'FooBarBaz.ONE|FooBarBaz.TWO'. In fact you can also cast and pass another 
enum type if you want.

enum FooBarBaz {
   ONE   = 0x1,
   TWO   = 0x2,
   THREE = 0x4,
   FOUR  = 0x8
}

enum BarBazFoo {
   ONE   = 0x8,
   TWO   = 0x4,
   THREE = 0x2,
   FOUR  = 0x1
}

void fooBar(FooBarBaz a) {
	printf("%x\n",a);
}

void main()
{
   int i = FooBarBaz.ONE|FooBarBaz.TWO;
   fooBar(i);  //function fooBar (FooBarBaz a) does not match argument 
types (int)
               //cannot implicitly convert expression i of type int to 
FooBarBaz
   fooBar(FooBarBaz.ONE|FooBarBaz.TWO);
   fooBar(cast(FooBarBaz)BarBazFoo.ONE|BarBazFoo.TWO);
}


 Arcane Jill
 (basically in support but with one or two niggling doubts).


Glad to see someone is thinking about how genreally 'nice' this would be 
without accusing me of being lazy.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 10 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opscjhxy015a2sq9 digitalmars.com>, Regan Heath says...


Glad to see someone is thinking about how genreally 'nice' this would be 
without accusing me of being lazy.


I take pride in being lazy. When I was studying math at school, I was taught
that math is all about being lazy, and that the very best mathematicians are the
laziest of all. If you cou prove a theorem ONCE for (say) "rings", then you've
proven it for reals, integers, whatever. There are parallels with OOP here -
component re-use is all about being lazy. I also write libraries because I'm
lazy (why write the same piece of code more than once?). I use Phobos routines
because I'm lazy (why write a piece of code at all if someone else has done it
for me?). I even write in D because I'm lazy (why invent my own brand new
computer language when I can just use Walter's?). I dunno, but I guess those mad
workaholic types just enjoy re-inventing the wheel all the time, or maybe they
just get a buzz out of pressing keys on their keyboard?

Jill
(Lazy and proud of it)
Aug 11 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cfcgjg$4v6$1 digitaldaemon.com>, Arcane Jill says...

In article <opscjhxy015a2sq9 digitalmars.com>, Regan Heath says...


Glad to see someone is thinking about how genreally 'nice' this would be 
without accusing me of being lazy.


I take pride in being lazy.


and of course
"efficience is the smart lazy"
(better wording welcome)

Ant
Aug 11 2004
parent Peter Wood <pwood iel.ie> writes:
Give the hardest job to the laziest person and they will find the quickest way
of doing it.


On Wed, 11 Aug 2004 12:30:56 +0000 (UTC)
Ant <Ant_member pathlink.com> wrote:


 In article <cfcgjg$4v6$1 digitaldaemon.com>, Arcane Jill says...

In article <opscjhxy015a2sq9 digitalmars.com>, Regan Heath says...


Glad to see someone is thinking about how genreally 'nice' this would be 
without accusing me of being lazy.


I take pride in being lazy.


 
 and of course
 "efficience is the smart lazy"
 (better wording welcome)
 
 Ant
Aug 11 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cfcgjg$4v6$1 digitaldaemon.com...

 I take pride in being lazy. When I was studying math at school, I was


taught

 that math is all about being lazy, and that the very best mathematicians


are the

 laziest of all. If you cou prove a theorem ONCE for (say) "rings", then


you've

 proven it for reals, integers, whatever. There are parallels with OOP


here -

 component re-use is all about being lazy. I also write libraries because


I'm

 lazy (why write the same piece of code more than once?). I use Phobos


routines

 because I'm lazy (why write a piece of code at all if someone else has


done it

 for me?). I even write in D because I'm lazy (why invent my own brand new
 computer language when I can just use Walter's?). I dunno, but I guess


those mad

 workaholic types just enjoy re-inventing the wheel all the time, or maybe


they

 just get a buzz out of pressing keys on their keyboard?


Most engineering progress is made by lazy people. The person who invented
automatic valves on steam engines was the boy who had to run up and down a
ladder for every stroke of the piston. He rigged up a pole and some levers
to do it for him, and was discovered asleep beside the engine, which was
running just fine.
Aug 13 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Regan Heath schrieb:


 Arcane Jill
 (basically in support but with one or two niggling doubts).


 
 Glad to see someone is thinking about how genreally 'nice' this would be 
 without accusing me of being lazy.


I would like to silently thumb up the remark and ideas as well.

-eye
Aug 13 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Regan Heath wrote:

 I have mentioned this before, but I kinda want some more opinions on the 
 matter/idea.
 
 Currently we have to specify an enum by it's full name, this can be 
 quite long and you can end up writing/copying/pasting the enum name a 
 few times.
 
 Surely it's possible in most cases for the compiler to determine the 
 Enum name and thus it's not really required.
 
 Example:
 
 enum FooBarBaz : ushort
 {
   THE   = 0x0001,
   QUICK = 0x0002,
   BROWN = 0x0004,
   FOX   = 0x0008,
   JUMPS = 0x0010,
   OVER  = 0x0020,
   THE   = 0x0040,
   LAZY  = 0x0080,
   DOG   = 0x0100
 }
 
 void fooBar(FooBarBaz a) {}
 
 void main()
 {
   //current method
   
 fooBar(FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.
AZY|FooBarBaz.DOG); 
 
 
   //proposed method
   fooBar(THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG);
 
   //alternate method
   fooBar(with(FooBarBaz){THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG});
 }


I don't think it's a good idea to get DMD guessing which namespaces to 
search when it can't find a symbol, nor does it feel like a particularly 
good idea to use the with() construct as an expression.

What would be simpler, and about as useful, though, would be if with() 
were also usable as an attribute specifier, like public/private/etc.

     class Foo {
         // Java-style
         with(FooBarBaz) const FooBarBaz flags = THE | QUICK | BROWN | FOX;

         // C++-style
     with (FooBarBaz):
         const FooBarBaz flags = ...;
     }

Incidently, it's becoming apparent that we have three different keywords 
for almost the same thing: with(), import, and alias. :)

  -- andy
Aug 11 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opschrxff75a2sq9 digitalmars.com...

 Surely it's possible in most cases for the compiler to determine the Enum
 name and thus it's not really required.


Making this work would break the bottom-up typing system of D expressions.
It has the potential of making the types of many expressions simply
unresolvable.
Aug 13 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opschrxff75a2sq9 digitalmars.com...
 

Surely it's possible in most cases for the compiler to determine the Enum
name and thus it's not really required.


 
 Making this work would break the bottom-up typing system of D expressions.
 It has the potential of making the types of many expressions simply
 unresolvable.


Why is this any harder than finding the names of things in imported files?
Aug 13 2004
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Russ Lewis wrote:

 Walter wrote:
 

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opschrxff75a2sq9 digitalmars.com...


 Surely it's possible in most cases for the compiler to determine the 
 Enum
 name and thus it's not really required.



 Making this work would break the bottom-up typing system of D 
 expressions.
 It has the potential of making the types of many expressions simply
 unresolvable.


 
 Why is this any harder than finding the names of things in imported files?


Ok, so to be just a little wacky, here's a enum-as-mixin

   enum Foo : uint { FOO, BAR, BAZ; };

turns into:

   template FooTemplate(T) {
     typedef T Foo;
     const T FOO = 0;
     const T BAR = 1;
     const T BAZ = 2;
   }
   mixin FooTemplate!(uint) FooM;

   void func(Foo f) { ... }
   func(FOO | BAR | BAZ);

   // if there is any ambiguity with other enums or local variables...
   func(FooM.FOO | FooM.BAR | FooM.BAZ);
Aug 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:cfjlm3$1cr3$1 digitaldaemon.com...

 Walter wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opschrxff75a2sq9 digitalmars.com...


Surely it's possible in most cases for the compiler to determine the






Enum

name and thus it's not really required.


 Making this work would break the bottom-up typing system of D




expressions.

 It has the potential of making the types of many expressions simply
 unresolvable.


 Why is this any harder than finding the names of things in imported files?


I hadn't thought of implementing it like an import, you might be right. I
think the semantics of looking up symbols in imports is straightforward, but
a lot of people here find it incomprehensible. I don't understand why, but
because of that I am hesitant to expand its application.
Aug 14 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cflk30$2io9$1 digitaldaemon.com>, Walter says...

I hadn't thought of implementing it like an import, you might be right. I
think the semantics of looking up symbols in imports is straightforward, but
a lot of people here find it incomprehensible. I don't understand why, but
because of that I am hesitant to expand its application.


Always seemed pretty straightforward to me.  And we're stuck with import
behavior for import anyway, so why not expand it to cover other areas where it
seems appropriate?  It would be better than having different rules for different
aspects of the language.


Sean
Aug 14 2004
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <cflk30$2io9$1 digitaldaemon.com>, Walter says...

 Why is this any harder than finding the names of things in imported files?


I hadn't thought of implementing it like an import, you might be right. I
think the semantics of looking up symbols in imports is straightforward, but
a lot of people here find it incomprehensible. I don't understand why, but
because of that I am hesitant to expand its application.


I say go for it! The import rules _are_ straightforward: if the identifier exist
in one module, use it. If it exists in more modules, complain. Use alias to
remove the complaints. That's it ;-)

Nick
Aug 14 2004
parent reply "antiAlias" <gblazzer corneleus.com> writes:
<groan>

Please ... no more alias ...


"Nick" <Nick_member pathlink.com> wrote in message
news:cfln3a$2k0p$1 digitaldaemon.com...

 In article <cflk30$2io9$1 digitaldaemon.com>, Walter says...

 Why is this any harder than finding the names of things in imported






files?

I hadn't thought of implementing it like an import, you might be right. I
think the semantics of looking up symbols in imports is straightforward,




but

a lot of people here find it incomprehensible. I don't understand why,




but

because of that I am hesitant to expand its application.


 I say go for it! The import rules _are_ straightforward: if the identifier


exist

 in one module, use it. If it exists in more modules, complain. Use alias


to

 remove the complaints. That's it ;-)

 Nick
Aug 14 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
antiAlias schrieb:


 <groan>
 
 Please ... no more alias ...


Ur, what?

Who are you anyway?

-eye/photoallergics
Aug 15 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
Ilya Minkov wrote:

 antiAlias schrieb:
 

 <groan>

 Please ... no more alias ...


 
 
 Ur, what?
 
 Who are you anyway?


If you can't guess who he is, he shouldn't have to bother telling you. 
Think about it... Think about whose name might have disappeared about 
the same time the new name appeared. Read antiAlias's posts. It's not 
that hard to figure out.


 
 -eye/photoallergics



-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Aug 15 2004
prev sibling parent reply "antiAlias" <gblazzer corneleus.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:cfnkur$hqi$1 digitaldaemon.com...

 Ur, what?

 Who are you anyway?

 -eye/photoallergics



<sigh>

If you perhaps had a sense of joviality you would already know. Or, if you'd
bother to look at prior posts, you would already know. My name is Kris, and,
if you'll graciously concede to it, I'll post under whatever "alias" suits;
just as others do.

That aside, I'm certainly entitled to my opinion. Just as you, apparently,
are entitled to your rather staunch opinion over a variety of matters.

Further; if you had any sense of etiquette, you'd understand that it's
considered rather 'uncool' to jostle individuals over their identity in a
public forum. Or perhaps you were being pompously arrogant instead.

I'll bid you "good-day"
Aug 15 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cfoa52$unf$1 digitaldaemon.com>, antiAlias says...


it's
considered rather 'uncool' to jostle individuals over their identity in a
public forum.


I agree with this, and I'd just like to remind everyone that the big W himself
(in post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3072) said:
"in general I'd like to request that we leave it up to the person using a handle
to reveal themselves or not as their choice".

Jill
Aug 15 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Arcane Jill schrieb:


 I agree with this, and I'd just like to remind everyone that the big W himself
 (in post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3072) said:
 "in general I'd like to request that we leave it up to the person using a
handle
 to reveal themselves or not as their choice".


Speaking of etiquette and such, it is usual that a person introduces 
himself or herself before speaking up. It is up to the person to share 
or not any personal data, but some piece of relevant information such as 
"I am new to D" or "I have been using D for a while" or "I have some 
experience in this other language" or "I have worked in this-or-that 
field of interest" or somesuch is in fact necessary for successful 
communication.

-eye
Aug 18 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
antiAlias schrieb:


 If you perhaps had a sense of joviality you would already know. Or, if you'd
 bother to look at prior posts, you would already know. My name is Kris, and,
 if you'll graciously concede to it, I'll post under whatever "alias" suits;
 just as others do.


I did take a short glance at them, but perhaps i missed the core. It is 
beyond my possibility to read everything on this newsgroup. And isn't it 
a bit arrogant of you to think that everyone should recognize you from 
one word? And though i do change my nicks from time to time, i have 
always posted under my real name.


 That aside, I'm certainly entitled to my opinion. Just as you, apparently,
 are entitled to your rather staunch opinion over a variety of matters.


I don't have a strong opinion on most matters, but i tend to support 
Walter unless i have been convinced otherwise. And i'm easy to convince.


 Further; if you had any sense of etiquette, you'd understand that it's
 considered rather 'uncool' to jostle individuals over their identity in a
 public forum. Or perhaps you were being pompously arrogant instead.


Yes, i am arrogant. But i'm nontheless sorry if this appeared hostile to 
you.

But look at it from my point of view. If i had recognized that it comes 
from you, it would be totally different, because i have read a number of 
posts from you, which make me think you are a smart person. And though i 
may be not always of the same opinion as you, i have come to respect 
your opinion because it has ground, and it's explained well, and you 
have a major influence on my opinion.

But the only thing i saw was someone i don't know just shouting out 
"BULLSHIT" without any explaination. So i just wanted to have that 
cleared up, whether the person has a reeason to say so. Under a certain 
kind of mood, i could have written a much more harsh message than i did 
if i had time.

-eye
Aug 18 2004
parent reply "antiAlias" <fu bar.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote ..

 beyond my possibility to read everything on this newsgroup. And isn't it
 a bit arrogant of you to think that everyone should recognize you from
 one word?


Now there's a 'spin' if ever I saw one. I'll do you a favour Ilya:
http://thesaurus.reference.com/search?q=pseudonym%20 . See those references
to "alias", "incognito", "anonym" ...



 But look at it from my point of view. If i had recognized that it comes
 from you, it would be totally different,


Ahh ... shallowness in its very finest guise.



 cleared up, whether the person has a reeason to say so. Under a certain
 kind of mood, i could have written a much more harsh message than i did
 if i had time.


Thrilled to hear you're such a truly thoughtful, warm, and charming
individual.
Aug 18 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
antiAlias schrieb:


 Now there's a 'spin' if ever I saw one. I'll do you a favour Ilya:
 http://thesaurus.reference.com/search?q=pseudonym%20 . See those references
 to "alias", "incognito", "anonym" ...


Should that add any value to the empty message of yours?


 Ahh ... shallowness in its very finest guise.


Pfft. And you are perfect and everyone should be like you. Omniscient 
amd omnipotent.


 Thrilled to hear you're such a truly thoughtful, warm, and charming
 individual.


Hrrr. Hr Hr Hr. :>>>>>>

-eye
Aug 19 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
Guys, guys. Please desist.

It pains me to see two smart chaps, both of whom I respect, in a slagging match.

Now if one of you were an idiot, I'd cheer insanely as I watched the unfair
crushing of the Christian in the lion's
jaws.

Simon the Softie

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:cg20pb$1qn9$1 digitaldaemon.com...

 antiAlias schrieb:


 Now there's a 'spin' if ever I saw one. I'll do you a favour Ilya:
 http://thesaurus.reference.com/search?q=pseudonym%20 . See those references
 to "alias", "incognito", "anonym" ...


 Should that add any value to the empty message of yours?


 Ahh ... shallowness in its very finest guise.


 Pfft. And you are perfect and everyone should be like you. Omniscient
 amd omnipotent.


 Thrilled to hear you're such a truly thoughtful, warm, and charming
 individual.


 Hrrr. Hr Hr Hr. :>>>>>>

 -eye
Aug 19 2004
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari cc.hut.fi> writes:
Regan Heath:

 I have mentioned this before, but I kinda want some more opinions on the 
 matter/idea.
 
 Currently we have to specify an enum by it's full name, this can be quite 
 long and you can end up writing/copying/pasting the enum name a few times.
 
 Surely it's possible in most cases for the compiler to determine the Enum 
 name and thus it's not really required.


I don't know if there was any kind of conclusion since I
skimmed this thread pretty quickly (several months of
catching up to do), but is this a possibility:

enum FooBarBaz : ushort
{
    THE = 0x0001,
    QUICK = 0x0002,
    BROWN = 0x0004,
    /* and what have you */
}

void fooBar(FooBarBaz a)
{
    {
        FooBarBaz x = THE;  // error - THE not in scope
        FooBarBaz y = FooBarBaz.THE // ok
    }
    {
        import FooBarBaz;   // bring names in FooBarBaz in current scope
        FooBarBaz x = THE;
    }
}

As this has a direct analogy in importing modules, there is
no new semantic baggage. And no need to complicate lookup rules,
I believe.

-Antti
Oct 27 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Antti Sykäri wrote:


 I don't know if there was any kind of conclusion since I
 skimmed this thread pretty quickly (several months of
 catching up to do), but is this a possibility:
 
 enum FooBarBaz : ushort
 {
     THE = 0x0001,
     QUICK = 0x0002,
     BROWN = 0x0004,
     /* and what have you */
 }
 
 void fooBar(FooBarBaz a)
 {
     {
         FooBarBaz x = THE;  // error - THE not in scope
         FooBarBaz y = FooBarBaz.THE // ok
     }
     {
         import FooBarBaz;   // bring names in FooBarBaz in current scope
         FooBarBaz x = THE;
     }
 }
 
 As this has a direct analogy in importing modules, there is
 no new semantic baggage. And no need to complicate lookup rules,
 I believe.


Here's the current dirty workaround that I resorted to:

//enum FooBarBaz : ushort
alias ushort FooBarBaz;
enum
{
     THE = 0x0001,
     QUICK = 0x0002,
     BROWN = 0x0004,
     /* and what have you */
}

Not type-safe, but "better" than porting all that C...


Some kind of import, like you suggest above, would be
a nice feature and minimize typing, and similar hacks.

Having to type the enum each time is about as tedious
as typing the full module name for each function call.

And "import" is a handy solution for that already, so...
(and with the "alias" to resolve any naming collision)

I couldn't find it in the FeatureRequestList, though ?

--anders
Oct 28 2004
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari cc.hut.fi> writes:
In article <clqc7n$1lf8$1 digitaldaemon.com>, Anders F Björklund wrote:

 Antti Sykäri wrote:


[my suggestion to pull names out of enums with import]

 
 Here's the current dirty workaround that I resorted to:


[...]

 
 Not type-safe, but "better" than porting all that C...

 Some kind of import, like you suggest above, would be
 a nice feature and minimize typing, and similar hacks.


Yes.

Better type-safe than sorry, right?. IMO language should not punish you
for wanting type safety.

"import" could be extended to other things than just enums - actually
everything that contain a namespace. While it would be most useful with
enums, occasionally I'd like to "import" some static members of
classes/interfaces/structs and template instances as well.


 I couldn't find it in the FeatureRequestList, though ?


So there was a list like that. Here's the URL to those that haven't
found it yet:

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Actually I went to wiki4d in the first place but couldn't find a link to
anything like that, so I gave up.

Back to the "import for enums,  than modules":
Perhaps I, or someone else, will need to write an entry in that list.

Is there any interest for a feature like this?

-Antti
Oct 28 2004