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


 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 +/
 }

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: # module a; # # enum ScreenColor { # RED = 1, # GREEN = 2, # BLUE = 3 } # # module b; # # enum PaintColor { # RED = 53, # GREEN = 85, # BLUE = 16 } # # module c; # # void PaintScreen( int color ) { ... } # # void main() { PaintScreen( RED ); } 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: # module a; # # enum ScreenColor { # RED = 1, # GREEN = 2, # BLUE = 3 } # # module b; # # enum PaintColor { # RED = 53, # GREEN = 85, # BLUE = 16 } # # module c; # # void PaintScreen( int color ) { ... } # # void main() { PaintScreen( RED ); } 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: # enum Qwerty { ONE=1, TWO=2 }; # void f(int x) { /*whatever*/ } # f(ONE); 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: # foo(cast(Test)(Test.ONE|Test.TWO)); 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: # enum A { ONE=1, TWO=2 }; # enum B { ONE=2, TWO=1 }; # void f(A x); # void f(B x); # f(ONE); 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: # enum Qwerty { ONE=1, TWO=2 }; # void f(int x) { /*whatever*/ } # f(ONE); 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:

 #   foo(cast(Test)(Test.ONE|Test.TWO));

 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: # enum A { ONE=1, TWO=2 }; # enum B { ONE=2, TWO=1 }; # void f(A x); # void f(B x); # f(ONE); 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: # struct MyFlags # { # unsigned int flag1 : 1; # unsigned int flag2 : 1; # unsigned int flag3 : 1; # unsigned int flag4 : 1; # }; # # struct MyFlags myFlags; # myFlags.flag2 = 1; # if (myflags.flag3) ... But of course you can't do that in D. In other langauges, I might do something like: # const uint FLAG1 = 0x01; # const uint FLAG2 = 0x02; # const uint FLAG3 = 0x04; # const uint FLAG4 = 0x08; # # int myFlags; # myFlags |= FLAG2; # if ((myFlags & FLAG3) != 0) ... although of course the code is then less typesafe. More likely, I'd just do: # bool flag1; # bool flag2; # bool flag3; # bool flag4; # # flag2 = true; # if (flag3) ... (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: # enum { FLAG1, FLAG2, FLAG3, FLAG4, NUM_FLAGS }; # bit[NUM_FLAGS] myFlags; # # myFlags[FLAG2] = true; # if (myFlags[FLAG3]) ... 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:

 #    enum { FLAG1, FLAG2, FLAG3, FLAG4, NUM_FLAGS };
 #    bit[NUM_FLAGS] myFlags;
 #
 #    myFlags[FLAG2] = true;
 #    if (myFlags[FLAG3]) ...

 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: # fooBar(THE); would work, since (assuming your proposed scheme) the compiler would be able to infer the type of the fooBar parameter. But as for # fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG); I have to ask - what is the compile-time type of the expression: # THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG 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: # fooBar(THE); would work, since (assuming your proposed scheme) the compiler would be able to infer the type of the fooBar parameter. But as for # fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG); I have to ask - what is the compile-time type of the expression: # THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG 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 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
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

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

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

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

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

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

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

 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

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

 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 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 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



name and thus it's not really required.

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


 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



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,


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


because of that I am hesitant to expand its application.

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

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

 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 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 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:

 
 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