www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug 3999 and 4261

reply bearophile <bearophileHUGS lycos.com> writes:
Probably each of the ~25 bugs of the short list I have shown here recently need
a bit of discussion (also because some of them are little breaking changes over
current DMD and/or TDPL). Even if some of them may need to wait in Bugzilla for
two years, it's positive to discuss them already. But you can't discuss all of
them at the same time.

This is one of them, chosen almost randomly, because it was recently commented
by Andrej Mitrovic:
http://d.puremagic.com/issues/show_bug.cgi?id=4261
It's related to:
http://d.puremagic.com/issues/show_bug.cgi?id=3999
http://d.puremagic.com/issues/show_bug.cgi?id=3308

I think bug 3999 shows the root of the situation, so I focus on it (indeed bug
4261 was not in that short list).
In C++0x Foo::V1 == 10 is a compile error, enum and int can't be compared
(don't miss the 'class' there):

enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}

test.cpp: In function 'int main()':
test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
test.cpp:3: note: candidates are: operator==(int, int) <built-in>


The point of the change suggested in bug 3999 is that this looks good to be
adopted in D too. Enumerated sequences in my opinion are less bug-prone if they
are true distinct types.

--------------------

Note: despite in D unfortuntately constants and enumerated values share the
same keyword, here I am not talking about constants like this one:

enum int foo = 10;

This foo is really of type int, it's not an enumeration, it's not a sequence of
symbols of length 1 named foo. Semantically it is another thing (this is also
why using the enum keyword for both things was the wrong choice).

Bye,
bearophile
Aug 31 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
A way to tell them apart is the presence of the EnumTag, if it's present, then
the enum is a new type:

enum V1 = 10;
enum { V2 = 20 }
enum Foo { V3 }
void main() {
    assert(V1 == 10);    // OK
    assert(V2 == 20);    // OK
    assert(Foo.V3 == 0); // ERROR, type mismatch
}

Bye,
bearophile
Aug 31 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
bearophile schrieb:

 A way to tell them apart is the presence of the EnumTag, if it's present, then
the enum is a new type:
 
 enum V1 = 10;
 enum { V2 = 20 }
 enum Foo { V3 }
 void main() {
     assert(V1 == 10);    // OK
     assert(V2 == 20);    // OK
     assert(Foo.V3 == 0); // ERROR, type mismatch
 }
 
 Bye,
 bearophile


I sometimes find it convenient to just treat those values as integers, 
e.g. when reading/writing them with a stream (to a file, to some other 
process with SocketStream, ...).
Like
---
int x;
stream.read(x); // btw: this often sucks - why not x = stream.readInt()?
if(x == MyEnum.DIE)
	return 0;
else if(x == MyEnum.CALLFOO)
	foo(x);
---
or something like that (switch() might be better, but whatever).

Also treating named and unnamed enums differently seems inconsistent to me.

Cheers,
- Daniel
Aug 31 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:mailman.24.1283298345.858.digitalmars-d puremagic.com...

 ---
 int x;
 stream.read(x); // btw: this often sucks - why not x = stream.readInt()?


Better yet: stream.read!int()


 if(x == MyEnum.DIE)
 return 0;
 else if(x == MyEnum.CALLFOO)
 foo(x);
 ---
 or something like that (switch() might be better, but whatever).

 Also treating named and unnamed enums differently seems inconsistent to 
 me.


D's enums are *already* two completely different things. Some enums create a 
new type with a pre-determined set of possible values, and some *ahem* 
"enum"s *cough* just simply create a manifst constant and no new type.

I gotta say, I'm completely with bearophile on these enum issues. One of the 
things that drew me to D from C/C++ is the increased emphasis on *strong* 
typing, but D's enums (and the death of typedef, athough I do understand the 
reasons for that) make me feel like I'm right back in the middle of C's 
shitty so-called "type system".

Plus, even if you do want to treat a...*real* enum (such as MyEnum above) as 
little more than a series of manifest constants (which I think is terrible 
design for an enum system), then the whole point of them is to replace magic 
numbers with real names. So if they get printed out as their base type, then 
we're right back into useless "magic number" territory. I've never once, in 
any language, printed out the value of an enum variable, gotten the value of 
the *base* type, and *not* needed to convert that back into the enum symbol 
name either in my head or by looking up the enum definition (or 
mechanically). And I've rarely, if ever, in any language, printed out the 
value of an enum variable, gotten the actual symbol name and actually needed 
the value of the base type instead.
Aug 31 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:

 I sometimes find it convenient to just treat those values as integers,


Yes, I am sure in some situations it can be handy. But it's a a bit of
convenience that has a too much high price, the semantics is less clean, and
it's more bug prone. So no thanks. Keeping things tidy is more important.

Bye,
bearophile
Aug 31 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
bearophile schrieb:

 Daniel Gibson:

 I sometimes find it convenient to just treat those values as integers,


 
 Yes, I am sure in some situations it can be handy. But it's a a bit of
convenience that has a too much high price, the semantics is less clean, and
it's more bug prone. So no thanks. Keeping things tidy is more important.
 
 Bye,
 bearophile


Then there still is the consistency-issue (anon. enums are treated 
differently then named enums).

Apart from that inconsistency: Yes, it wouldn't be unreasonable to just 
cast the int to MyEnum or the other way round for comparison.
(or, in my example: MyEnum x; stream.read(cast(int)x); ...)

Cheers,
- Daniel
Aug 31 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:

 Then there still is the consistency-issue (anon. enums are treated 
 differently then named enums).


Look at this:Se
enum int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...

Color is a sequence of symbols, Red, Green and Blue, named Color. When you
write your program often all you need to know is if color is Red or Green, and
you don't care much how the compiler represents those symbols.
The n is a compile-time constant value. It's not a sequence of something.

Now, just for fun, replace the first enum with something as:

ctconst int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...

ctconst is a fictional keyword that denotes compile-time constants. Now you are
probably able to see that there is no correlation between the n and Color.

In D they are using the same keyword by accident, probably because Walter
thinks that saving a keyword is more important than keeping the semantics tidy.
So today you are probably struck with using "enum" to define compile-time
constants.

The C++0x design group has not introduced the "enum class" for fun, their
strong typing nature is useful to make the code less bug-prone. See:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf

See for example "Problem 1: Implicit conversion to an integer".

Bye,
bearophile
Aug 31 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
bearophile wrote:

 
 ctconst is a fictional keyword that denotes compile-time constants. Now you
are probably able to see that there is no correlation between the n and Color.
 


Why not use the non-fictional const keyword? "The const attribute 
declares constants that can be evaluated at compile time."[1]

"enum int n = 10;" looks really strange. I don't know if this is needed..
But "enum : int { FOO, BAR, BAZ };" does not look so strange to me and 
I'd prefer this to "const int FOO=0; const int BAR=1; const int BAZ=2;".
The syntax is shorter, it shows that these keywords kind of belong 
together and the values are enumerated automatically.

Cheers,
- Daniel

[1] http://www.digitalmars.com/d/1.0/attribute.html#const
Aug 31 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:


 Why not use the non-fictional const keyword? "The const attribute 
 declares constants that can be evaluated at compile time."[1]


But you can use const for constants that are known at run-time only. While you
can't use enum for constant known at run-time.



 "enum int n = 10;" looks really strange. I don't know if this is needed..


I think it helps in a linker issue. But I am not expert on this. Maybe LDC
(based on LLVM) doesn't need enums much.



 But "enum : int { FOO, BAR, BAZ };" does not look so strange to me and 
 I'd prefer this to "const int FOO=0; const int BAR=1; const int BAZ=2;".
 The syntax is shorter, it shows that these keywords kind of belong 
 together and the values are enumerated automatically.


I agree, and I have never said I want to disallow it. You can cast those FOO,
BAR, etc implicitly to int. It's the example V2 I have shown, no error there:

enum V1 = 10;
enum { V2 = 20 }
enum Foo { V3 }
void main() {
    assert(V1 == 10);    // OK
    assert(V2 == 20);    // OK
    assert(Foo.V3 == 0); // ERROR, type mismatch
}

Thank you for your doubts and questions, they help me express better what I
meant. It seems I was not clear enough at the beginning.

Bye,
bearophile
Aug 31 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
bearophile schrieb:

 Daniel Gibson:
 

 Why not use the non-fictional const keyword? "The const attribute 
 declares constants that can be evaluated at compile time."[1]


 
 But you can use const for constants that are known at run-time only. While you
can't use enum for constant known at run-time.
 


Really? Than that definition from the language docs is inaccurate.


 

 "enum int n = 10;" looks really strange. I don't know if this is needed..


 
 I think it helps in a linker issue. But I am not expert on this. Maybe LDC
(based on LLVM) doesn't need enums much.
 
 

 But "enum : int { FOO, BAR, BAZ };" does not look so strange to me and 
 I'd prefer this to "const int FOO=0; const int BAR=1; const int BAZ=2;".
 The syntax is shorter, it shows that these keywords kind of belong 
 together and the values are enumerated automatically.


 
 I agree, and I have never said I want to disallow it. You can cast those FOO,
BAR, etc implicitly to int. It's the example V2 I have shown, no error there:
 
 enum V1 = 10;
 enum { V2 = 20 }
 enum Foo { V3 }
 void main() {
     assert(V1 == 10);    // OK
     assert(V2 == 20);    // OK
     assert(Foo.V3 == 0); // ERROR, type mismatch
 }
 
 Thank you for your doubts and questions, they help me express better what I
meant. It seems I was not clear enough at the beginning.
 
 Bye,
 bearophile


I know what you meant - but my point is that anon. enums make sense (I 
guess we agree on that one) and that allowing implicit casting to int 
for them and not for named enums seems inconsistent.
Of course disallowing implicit casting for anon. enums is not really an 
options (how should that even work.. maybe "cast(enum:int)foo" or 
something like that..) so IMHO a reasonable solution is keeping it the 
way it is.

Cheers,
- Daniel
Aug 31 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:


 Really? Than that definition from the language docs is inaccurate.


This compiles, here n is known at run-time only:

void main(string[] args) {
    const int n = args.length;
}

This compiles, but I think it's a bug:

void main(string[] args) {
    enum int n = args.length;
}


This shows that there is a problem:

template Foo(int n) {
}
void main(string[] args) {
    enum int n = args.length;
    alias Foo!(n) _;
}




 I know what you meant - but my point is that anon. enums make sense (I 
 guess we agree on that one) and that allowing implicit casting to int 
 for them and not for named enums seems inconsistent.


The real inconstancy is using 'enum' for them both in the first place. They are
conceptually two different things. It looks inconsistent if you think of them
as similar things.

But even if you like to think of them as the same thing, you may think of my
proposal as a way to enforce more strong typing, to remove a subset of the
allowed behaviours of one subclass of those enum thinghies that you think are
all the same thing. So you may see it as an inconstancy introduced on purpose
to remove some risky behaviours. D has introduced some other of such
'inconsistencies' (compared to a uniform C behaviour) where they help disallow
some behaviours that are regarded as negative.



 Of course disallowing implicit casting for anon. enums is not really an 
 options (how should that even work.. maybe "cast(enum:int)foo" or 
 something like that..)


Right.



so IMHO a reasonable solution is keeping it the way it is.


In my opinion (and probably in the opinion of the people that are designing
C++x0) this is not a good enough solution, because it's a little error-prone.

Bye,
bearophile
Aug 31 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:i5kbpr$24tn$1 digitalmars.com...

 bearophile schrieb:

 Daniel Gibson:


 Why not use the non-fictional const keyword? "The const attribute 
 declares constants that can be evaluated at compile time."[1]


 But you can use const for constants that are known at run-time only. 
 While you can't use enum for constant known at run-time.


 Really? Than that definition from the language docs is inaccurate.


You were looking at the D1 docs. The whole const system changed in D2.
Aug 31 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Nick Sabalausky schrieb:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:i5kbpr$24tn$1 digitalmars.com...

 bearophile schrieb:

 Daniel Gibson:


 Why not use the non-fictional const keyword? "The const attribute 
 declares constants that can be evaluated at compile time."[1]


 But you can use const for constants that are known at run-time only. 
 While you can't use enum for constant known at run-time.


 Really? Than that definition from the language docs is inaccurate.


 
 You were looking at the D1 docs. The whole const system changed in D2. 
 


http://www.digitalmars.com/d/2.0/attribute.html#const says the same.
Sep 01 2010
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:i5lrkr$1ijr$1 digitalmars.com...

 Nick Sabalausky schrieb:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:i5kbpr$24tn$1 digitalmars.com...

 bearophile schrieb:

 Daniel Gibson:


 Why not use the non-fictional const keyword? "The const attribute 
 declares constants that can be evaluated at compile time."[1]


 But you can use const for constants that are known at run-time only. 
 While you can't use enum for constant known at run-time.


 Really? Than that definition from the language docs is inaccurate.


 You were looking at the D1 docs. The whole const system changed in D2.


 http://www.digitalmars.com/d/2.0/attribute.html#const says the same.


Yea, that's probably wrong then. Unless there's something I don't know.
Sep 01 2010
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
This whole enum thing is making my head explode out of confusion. I
thought having a tag was just supossed to be used as a namespace for
enumerated values. E.g.:

enum { red =3D 1, green, blue }
...
if (getValue() =3D=3D green) {
    do..
}

and:

enum Tagged { red =3D 1, green, blue }
...
if (getValue() =3D=3D Tagged.green) {  // safer version
    do..
}

That is all that I thought enums are useful for. But apparently an
enum is a type and you can instantiate it.... and I don't even know
what an enum is anymore. I'll just stay out of this discussion for
now, lol. :)


 I agree, and I have never said I want to disallow it. You can cast those =


FOO, BAR, etc implicitly to int. It's the example V2 I have shown, no error=
 there:

 enum V1 =3D 10;
 enum { V2 =3D 20 }
 enum Foo { V3 }
 void main() {
 =A0 =A0assert(V1 =3D=3D 10); =A0 =A0// OK
 =A0 =A0assert(V2 =3D=3D 20); =A0 =A0// OK
 =A0 =A0assert(Foo.V3 =3D=3D 0); // ERROR, type mismatch
 }

 Thank you for your doubts and questions, they help me express better what=


 I meant. It seems I was not clear enough at the beginning.

 Bye,
 bearophile
Aug 31 2010
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.28.1283307608.858.digitalmars-d puremagic.com...

That is all that I thought enums are useful for. But apparently an
enum is a type and you can instantiate it.... and I don't even know
what an enum is anymore. I'll just stay out of this discussion for
now, lol. :)


This is the way I've always seen an enum:

An enum is a custom type with a pre-defined set of possible values, each 
individually-named. That's the primary purpose. Typically, an enum will have 
a "base" type which determines the physical in-memory representation of the 
values and allows for a convenient (but not accidentally-invoked) one-to-one 
mapping between the enum values and certain values from one other 
user-chosen type (ie, the base type).
Aug 31 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 8/31/2010 19:46, bearophile wrote:

 But you can use const for constants that are known at run-time only.
 While you can't use enum for constant known at run-time.


In C++, const is used for both run-time and compile-time constants.  In
practice, this works out fine.  It its value can only be known at
run-time, it's a run-time constant.  If its value is used at
compile-time, it's a compile-time constant.  If both of these apply,
it's an error.  If neither applies, nobody cares if it's a compile-time
or run-time constant.

(The actual rules in C++ are a bit more complex, less intuitive, and
less useful than that, which is presumably why Walter chose not to copy
the C++ in this case.  Still, overloading 'const' for both compile-time
and run-time constants is viable, and more intuitive than the current
situation with 'enum'.)


-- 
Rainer Deyke - rainerd eldwood.com
Sep 01 2010
next sibling parent Don <nospam nospam.com> writes:
Rainer Deyke wrote:

 On 8/31/2010 19:46, bearophile wrote:

 But you can use const for constants that are known at run-time only.
 While you can't use enum for constant known at run-time.


 
 In C++, const is used for both run-time and compile-time constants.  In
 practice, this works out fine.  It its value can only be known at
 run-time, it's a run-time constant.  If its value is used at
 compile-time, it's a compile-time constant.  If both of these apply,
 it's an error.  If neither applies, nobody cares if it's a compile-time
 or run-time constant.
 
 (The actual rules in C++ are a bit more complex, less intuitive, and
 less useful than that, which is presumably why Walter chose not to copy
 the C++ in this case.  Still, overloading 'const' for both compile-time
 and run-time constants is viable, and more intuitive than the current
 situation with 'enum'.)


The enum situation exists ONLY because of linker limitations. It seems 
most people still don't understand that.
Sep 01 2010
prev sibling parent reply so <so so.do> writes:
On Wed, 01 Sep 2010 11:06:51 +0300, Rainer Deyke <rainerd eldwood.com>  
wrote:


 On 8/31/2010 19:46, bearophile wrote:

 But you can use const for constants that are known at run-time only.
 While you can't use enum for constant known at run-time.


 In C++, const is used for both run-time and compile-time constants.  In
 practice, this works out fine.  It its value can only be known at
 run-time, it's a run-time constant.  If its value is used at
 compile-time, it's a compile-time constant.  If both of these apply,
 it's an error.  If neither applies, nobody cares if it's a compile-time
 or run-time constant.

 (The actual rules in C++ are a bit more complex, less intuitive, and
 less useful than that, which is presumably why Walter chose not to copy
 the C++ in this case.  Still, overloading 'const' for both compile-time
 and run-time constants is viable, and more intuitive than the current
 situation with 'enum'.)


I have never had troubles with C++ compile/runtime "const" difference,
and don't think it is a problem in C++. With this in mind "enum" is a  
great keyword
of choice to express compile-time types, as long as it is forbidden for  
run-time constants.
(I hope that example of bearophile is just a bug.)

Thanks.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Sep 01 2010
next sibling parent so <so so.do> writes:
 (I hope that example of bearophile is just a bug.)


This one.

void main(string[] args) {
     enum int n = args.length;
}

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Sep 01 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
so:

 (I hope that example of bearophile is just a bug.)


I have added it as bug 4786

Bye,
bearophile
Sep 01 2010
prev sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, September 01, 2010 11:58:39 so wrote:

 I have never had troubles with C++ compile/runtime "const" difference,
 and don't think it is a problem in C++. With this in mind "enum" is a
 great keyword
 of choice to express compile-time types, as long as it is forbidden for
 run-time constants.
 (I hope that example of bearophile is just a bug.)
 
 Thanks.


C++ doesn't have CTFE. CTFE is why it really matters in D. If you're dealing 
with a compile-time constant, it uses CTFE. If you're dealing with a runtime 
constant, it doesn't. So, you need to be explicit.

Personally, I don't really care about using enum the way it is. Having enums 
freely converting to and from their base type is more of a concern, though I'm 
not sure how much that really does or doesn't matter. It's quite clear when an 
enum is used as a manifest constant and when it's used as an enum, so I don't 
really see a problem with the way it is, though I can see why someone wouldn't 
like it.

- Jonathan M Davis
Sep 01 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.33.1283368612.858.digitalmars-d puremagic.com...

 Personally, I don't really care about using enum the way it is. Having 
 enums
 freely converting to and from their base type is more of a concern, though 
 I'm
 not sure how much that really does or doesn't matter.


I find it to be a pain nearly every time I need to convert one to a string.
Sep 01 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, September 01, 2010 12:59:01 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.33.1283368612.858.digitalmars-d puremagic.com...
 

 Personally, I don't really care about using enum the way it is. Having
 enums
 freely converting to and from their base type is more of a concern,
 though I'm
 not sure how much that really does or doesn't matter.


 
 I find it to be a pain nearly every time I need to convert one to a string.


I wasn't even aware that there was a way. If I had to guess, I would assume
that 
it involves stringof, but I'd have to try it. Now, assuming that that's the 
case, it would be pretty easy to write a template function which takes the enum 
type and the value to stringify, and it returns the string version of that enum 
value (or throws if it's not a valid value for that enum type). I can see how 
having it as a distinct type would be more desirable for that though, since
then 
you could likely just use stringof on it directly.

- Jonathan M Davis
Sep 01 2010
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I thought to!string(Enum) already does this? This was the example I
posted in bug report 4261:

import std.conv : to;
import std.stdio: writeln;
void main()
{
    enum Foo { Zero, One }
    Foo f = Foo.One;
    writeln(to!string(f));
}

Prints: One

On Wed, Sep 1, 2010 at 10:50 PM, Jonathan M Davis <jmdavisprog gmail.com> wrote:

 On Wednesday, September 01, 2010 12:59:01 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.33.1283368612.858.digitalmars-d puremagic.com...


 Personally, I don't really care about using enum the way it is. Having
 enums
 freely converting to and from their base type is more of a concern,
 though I'm
 not sure how much that really does or doesn't matter.


 I find it to be a pain nearly every time I need to convert one to a string.


 I wasn't even aware that there was a way. If I had to guess, I would assume
that
 it involves stringof, but I'd have to try it. Now, assuming that that's the
 case, it would be pretty easy to write a template function which takes the enum
 type and the value to stringify, and it returns the string version of that enum
 value (or throws if it's not a valid value for that enum type). I can see how
 having it as a distinct type would be more desirable for that though, since
then
 you could likely just use stringof on it directly.

 - Jonathan M Davis
Sep 01 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.49.1283374449.858.digitalmars-d puremagic.com...

I thought to!string(Enum) already does this? This was the example I
 posted in bug report 4261:

 import std.conv : to;
 import std.stdio: writeln;
 void main()
 {
    enum Foo { Zero, One }
    Foo f = Foo.One;
    writeln(to!string(f));
 }

 Prints: One


Does it really work that way now? That must have changed then. I could swear 
it wasn't like that before.
Sep 01 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
That's how it's described in TDPL, and yes it works.

On Wed, Sep 1, 2010 at 11:38 PM, Nick Sabalausky <a a.a> wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.49.1283374449.858.digitalmars-d puremagic.com...

I thought to!string(Enum) already does this? This was the example I
 posted in bug report 4261:

 import std.conv : to;
 import std.stdio: writeln;
 void main()
 {
 =A0 =A0enum Foo { Zero, One }
 =A0 =A0Foo f =3D Foo.One;
 =A0 =A0writeln(to!string(f));
 }

 Prints: One


 Does it really work that way now? That must have changed then. I could sw=


ear

 it wasn't like that before.
Sep 01 2010
prev sibling next sibling parent reply so <so so.do> writes:
 ctconst is a fictional keyword that denotes compile-time constants. Now  
 you are probably able to see that there is no correlation between the n  
 and Color.

 In D they are using the same keyword by accident, probably because  
 Walter thinks that saving a keyword is more important than keeping the  
 semantics tidy.
 So today you are probably struck with using "enum" to define  
 compile-time constants.

 The C++0x design group has not introduced the "enum class" for fun,  
 their strong typing nature is useful to make the code less bug-prone.  
 See:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf

 See for example "Problem 1: Implicit conversion to an integer".

 Bye,
 bearophile


Another taste discussion? Enum, again for "my taste" a great find for the  
job.
Bugs aside, i can't seem to follow you.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Sep 01 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
so:

 Another taste discussion?


Nope.

-----------------

Steven Schveighoffer:

And I think if you have an idea to try and "fix" it, you might as well know
now, it will never happen.<


There I was explaining something better to Daniel Gibson. The purpose of the
enhancement request 3999 has nothing to do with a request for a different
keyword.

-----------------

I think now I have presented my point as well as I can, and people have given
comments and opinions. I'd like to Walter or/and Andrei to express their
opinion about the bug 3999 :-)

Bye,
bearophile
Sep 01 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/1/10 15:35 CDT, bearophile wrote:

 so:

 Another taste discussion?


 Nope.

 -----------------

 Steven Schveighoffer:

 And I think if you have an idea to try and "fix" it, you might as well know
now, it will never happen.<


 There I was explaining something better to Daniel Gibson. The purpose of the
enhancement request 3999 has nothing to do with a request for a different
keyword.

 -----------------

 I think now I have presented my point as well as I can, and people have given
comments and opinions. I'd like to Walter or/and Andrei to express their
opinion about the bug 3999 :-)


I think it's a good enhancement. C++'s good old enum has been 
instrumental in finding a few bugs and clarifying a few interfaces in a 
project at work. Based on that experience I'd say that there's a chance 
more restrictive is better. We need to find a principled way to define 
semantics though - if we disable comparison it really means we're 
disabling implicit conversion.

Andrei
Sep 01 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i5mfji$2qtd$1 digitalmars.com...

 I think it's a good enhancement. C++'s good old enum has been instrumental 
 in finding a few bugs and clarifying a few interfaces in a project at 
 work. Based on that experience I'd say that there's a chance more 
 restrictive is better. We need to find a principled way to define 
 semantics though - if we disable comparison it really means we're 
 disabling implicit conversion.


"...it really means we're disabling implicit conversion"

And that's a problem?
Sep 01 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/1/10 16:39 CDT, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i5mfji$2qtd$1 digitalmars.com...

 I think it's a good enhancement. C++'s good old enum has been instrumental
 in finding a few bugs and clarifying a few interfaces in a project at
 work. Based on that experience I'd say that there's a chance more
 restrictive is better. We need to find a principled way to define
 semantics though - if we disable comparison it really means we're
 disabling implicit conversion.


 "...it really means we're disabling implicit conversion"

 And that's a problem?


It's bound to break some code.

Andrei
Sep 01 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 I think it's a good enhancement.


Good :-)



 C++'s good old enum has been 
 instrumental in finding a few bugs and clarifying a few interfaces in a 
 project at work. Based on that experience I'd say that there's a chance 
 more restrictive is better.


There is also the experience of the C++0x group of designers, and their "enum
class". One of the purpose of those "enum class" is to remove implicit
conversions to int:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf



 We need to find a principled way to define 
 semantics though - if we disable comparison it really means we're 
 disabling implicit conversion.


I agree.

If bug bug 3999 gets accepted in the form I meant, then probably the bug 4261
too may be considered, because then enums aren't "ints" and the most natural
way to print them on default is by name and not by hidden representation value:
http://d.puremagic.com/issues/show_bug.cgi?id=4261



 It's bound to break some code.


Yes, several of the about 25 entries of my 'short list' I have recently shown
here are able to break some code. This is why I am showing them here now. I
think of those bug reports are more "important" than the others I have put in
Bugzilla because as more and more D2 code gets written, even tiny breaking
changes become harder and harder to justify.

Bye,
bearophile
Sep 01 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 01 Sep 2010 17:12:04 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 9/1/10 15:35 CDT, bearophile wrote:

 so:

 Another taste discussion?


 Nope.

 -----------------

 Steven Schveighoffer:

 And I think if you have an idea to try and "fix" it, you might as well  
 know now, it will never happen.<


 There I was explaining something better to Daniel Gibson. The purpose  
 of the enhancement request 3999 has nothing to do with a request for a  
 different keyword.

 -----------------

 I think now I have presented my point as well as I can, and people have  
 given comments and opinions. I'd like to Walter or/and Andrei to  
 express their opinion about the bug 3999 :-)


 I think it's a good enhancement. C++'s good old enum has been  
 instrumental in finding a few bugs and clarifying a few interfaces in a  
 project at work. Based on that experience I'd say that there's a chance  
 more restrictive is better. We need to find a principled way to define  
 semantics though - if we disable comparison it really means we're  
 disabling implicit conversion.


Does this mean no more defining bits as enums?

enum myBits
{
    flag1 = 1;
    flag2 = 2;
    flag3 = 4;
}

void fn(int flags);

fn(myBits.flag1 | myBits.flag2);

That was the one case where I really like the implicit conversion.

-Steve
Sep 02 2010
parent reply so <so so.do> writes:
 Does this mean no more defining bits as enums?


Now that would be brutal, it is one of the best use cases of enum if not  
the best...

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Sep 02 2010
parent reply Don <nospam nospam.com> writes:
so wrote:

 Does this mean no more defining bits as enums?


 
 Now that would be brutal, it is one of the best use cases of enum if not 
 the best...


Yes.
I reckon, if an enum doesn't explicitly define the value of each member, 
it shouldn't implicitly convert to int -- and it should not be possible 
to treat it as bits.

OTOH if each member has an explicitly defined value, it's reasonable to 
perform logical operations on it.
Sep 02 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 OTOH if each member has an explicitly defined value, it's reasonable to 
 perform logical operations on it.


See my recent answer to Schveighoffer. I think that's not a fully good idea
because when you define an enum like that and you use its values as
powers-of-two flags, the type system doesn't help you enforce it is a true
combination of the flags instead of a generic number (and you may put bugs when
you define the values to assign to the flags), so I think something like a
std.bitmanip.flagset that produces a struct is better when you need to define a
flag set.

Bye,
bearophile
Sep 02 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:i5p63u$2pl1$1 digitalmars.com...

 Don:

 OTOH if each member has an explicitly defined value, it's reasonable to
 perform logical operations on it.


 See my recent answer to Schveighoffer. I think that's not a fully good 
 idea because when you define an enum like that and you use its values as 
 powers-of-two flags, the type system doesn't help you enforce it is a true 
 combination of the flags instead of a generic number (and you may put bugs 
 when you define the values to assign to the flags), so I think something 
 like a std.bitmanip.flagset that produces a struct is better when you need 
 to define a flag set.


I think all the discussions we've had about enum make it clear that enum 
suffers from a bit of an identity crisis. It doesn't know what it is and 
ends up being mediocre at everything it dabbles in.
Sep 02 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
  the type system doesn't help you enforce it is a true combination of the
flags instead of a generic number


I have used std.bitmanip.bitfields some time, and in my opinion its best
quality is its overflow tests. They have caught few of my bugs (it's easy to
overflow such little numbers). It's also another good example why having
runtime integer overflow tests is a Good Thing.

Bye,
bearophile
Sep 02 2010
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:

 OTOH if each member has an explicitly defined value, it's reasonable to 
 perform logical operations on it.


 
 See my recent answer to Schveighoffer. I think that's not a fully good idea
because when you define an enum like that and you use its values as
powers-of-two flags, the type system doesn't help you enforce it is a true
combination of the flags instead of a generic number (and you may put bugs when
you define the values to assign to the flags), so I think something like a
std.bitmanip.flagset that produces a struct is better when you need to define a
flag set.
 
 Bye,
 bearophile


That's impossible. That would make interfacing to C a nightmare.
By the way, enums which consist of flags frequently have values which 
have more than one bit set. The case { A=1, B=2, C=4, D=8 } is only a 
special case.
In the general case, it's not realistic to hope that the compiler could 
determine which values are valid, and which are not.
But, with my suggestion, simple enums (a list of mutually exclusive 
values) would become strong enums.
Sep 02 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I just stumbled upon this in std.typecons:

http://www.digitalmars.com/d/2.0/phobos/std_typecons.html#defineEnum

Might be useful from some, I guess.


On Fri, Sep 3, 2010 at 7:09 AM, Don <nospam nospam.com> wrote:





 Sep 03 2010



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Andrej Mitrovic:


 I just stumbled upon this in std.typecons:
 http://www.digitalmars.com/d/2.0/phobos/std_typecons.html#defineEnum
 Might be useful from some, I guess.


Thank you. I think std.typecons.defineEnum() may be removed. I don't think it's
useful now.

Bye,
bearophile



 Sep 03 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 9/3/10 11:58 CDT, bearophile wrote:

 Andrej Mitrovic:


 I just stumbled upon this in std.typecons:
 http://www.digitalmars.com/d/2.0/phobos/std_typecons.html#defineEnum
 Might be useful from some, I guess.


 Thank you. I think std.typecons.defineEnum() may be removed. I don't think
it's useful now.

 Bye,
 bearophile


Yah, that artifact predates the introspection means that make printing 
and parsing for enums possible.

Andrei



 Sep 03 2010



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 31 Aug 2010 20:59:15 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Daniel Gibson:

 Then there still is the consistency-issue (anon. enums are treated
 differently then named enums).


 Look at this:Se
 enum int n = 10;
 enum Color { Red, Green, Blue }
 Color color;
 if (color == Color.Red) { ...

 Color is a sequence of symbols, Red, Green and Blue, named Color. When  
 you write your program often all you need to know is if color is Red or  
 Green, and you don't care much how the compiler represents those symbols.
 The n is a compile-time constant value. It's not a sequence of something.

 Now, just for fun, replace the first enum with something as:

 ctconst int n = 10;
 enum Color { Red, Green, Blue }
 Color color;
 if (color == Color.Red) { ...

 ctconst is a fictional keyword that denotes compile-time constants. Now  
 you are probably able to see that there is no correlation between the n  
 and Color.

 In D they are using the same keyword by accident, probably because  
 Walter thinks that saving a keyword is more important than keeping the  
 semantics tidy.


AFAIK, enum meaning manifest constant was Andrei's request.  And I think  
if you have an idea to try and "fix" it, you might as well know now, it  
will never happen.  See this quote from Andrei in a bug report of mine  
(bug 1961):

"And enum... you'll have to yank that out from my dead cold hands.  
Extending
enum instead of adding yet another way of defining symbolic constants is  
The
Right Thing to do. I am sure people would have realized how ridiculous the
whole "manifest" thing is if we first proposed it. We just can't define one
more way for each kind of snow there is."

There was a point in D2 development with the 'manifest' keyword added to  
do exactly what enum now does (except for actual enumerations, for which  
enum was used).

FWIW, I am not a huge fan of enum being used for meaning manifest  
constants that are not enumerations, but as far as daily usage, it's not  
really bad.  It's somewhat of a petty problem, since enum is not  
functionally deficient.  It just looks weird, especially to those used to  
other languages.  I suppose you could think of it as an enumeration with  
one member :)

-Steve



 Sep 01 2010



  parent reply Jonathan M Davis <jmdavisprog gmail.com>  writes:


On Wednesday, September 01, 2010 12:36:04 Steven Schveighoffer wrote:

 AFAIK, enum meaning manifest constant was Andrei's request.  And I think
 if you have an idea to try and "fix" it, you might as well know now, it
 will never happen.  See this quote from Andrei in a bug report of mine
 (bug 1961):
 
 "And enum... you'll have to yank that out from my dead cold hands.
 Extending
 enum instead of adding yet another way of defining symbolic constants is
 The
 Right Thing to do. I am sure people would have realized how ridiculous the
 whole "manifest" thing is if we first proposed it. We just can't define one
 more way for each kind of snow there is."
 
 There was a point in D2 development with the 'manifest' keyword added to
 do exactly what enum now does (except for actual enumerations, for which
 enum was used).
 
 FWIW, I am not a huge fan of enum being used for meaning manifest
 constants that are not enumerations, but as far as daily usage, it's not
 really bad.  It's somewhat of a petty problem, since enum is not
 functionally deficient.  It just looks weird, especially to those used to
 other languages.  I suppose you could think of it as an enumeration with
 one member :)
 
 -Steve


It's the kind of thing that is distasteful from a language purity standpoint, 
but it really doesn't cause any problems in code as far as I can tell. Once you 
know that you use enum to declare a manifest constant, it's perfectly normal to 
see it in code that way, so it's not confusing. And since you're not going to 
try to enumerate over such enums, it's not like they cause any real confusion 
with "normal" enums.

You can think of it a bit like static. Static is used for different things in 
different contexts (even though most contexts are quite similar - IIRC, there's
a 
way to define static in C++ which fits all of its uses in C++, though D adds
some 
more that don't fit that definitition), but it doesn't really cause any
confusion. 
enum is the same way. Sure, from the standpoint of language purity, manifest 
constants shouldn't be declared using enum, but the reality of the matter is 
that it works just fine.

- Jonathan M Davis



 Sep 01 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.38.1283370572.858.digitalmars-d puremagic.com...

 You can think of it a bit like static. Static is used for different things 
 in
 different contexts (even though most contexts are quite similar - IIRC, 
 there's a
 way to define static in C++ which fits all of its uses in C++, though D 
 adds some
 more that don't fit that definitition), but it doesn't really cause any 
 confusion.
 enum is the same way. Sure, from the standpoint of language purity, 
 manifest
 constants shouldn't be declared using enum, but the reality of the matter 
 is
 that it works just fine.


Static is a little bit better in that the uses of it at least have some 
connection to the dictionary meaning of "static", even if perhaps a little 
distant. But there's just no way to stretch the dictionary meaning of 
"enumeration" to include manifest constants. Like everyone else, I can at 
least live with it, but I look forward to the day the linker issue is fixed 
so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme 
prejudice in favor of immutable. It's a stain - doesn't really cause a 
problem, but boy is it ever UGLY. 



 Sep 01 2010



  parent reply so <so so.do>  writes:


 Static is a little bit better in that the uses of it at least have some
 connection to the dictionary meaning of "static", even if perhaps a  
 little
 distant. But there's just no way to stretch the dictionary meaning of
 "enumeration" to include manifest constants. Like everyone else, I can at
 least live with it, but I look forward to the day the linker issue is  
 fixed
 so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme
 prejudice in favor of immutable. It's a stain - doesn't really cause a
 problem, but boy is it ever UGLY.


Float is not floating and double is not doubling, are they next?

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Sep 01 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"so" <so so.do> wrote in message news:op.videg00w7dtt59 so-pc...

 Static is a little bit better in that the uses of it at least have some
 connection to the dictionary meaning of "static", even if perhaps a 
 little
 distant. But there's just no way to stretch the dictionary meaning of
 "enumeration" to include manifest constants. Like everyone else, I can at
 least live with it, but I look forward to the day the linker issue is 
 fixed
 so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme
 prejudice in favor of immutable. It's a stain - doesn't really cause a
 problem, but boy is it ever UGLY.


 Float is not floating and double is not doubling, are they next?


Float (short for "floating point"): The decimal point can "float" around as 
the value changes (not a literal use of "float", but there's nothing wrong 
with metaphoric uses of words, even in ordinary speech). This type is named 
in contrast to the fixed-point arithmetic that was often used as an 
old-school optimization (where the decimal point was always at a fixed 
location, for example, the high 16-bits may have been the whole-number part, 
and the low 16-bits may have been the decimal part).

Double: This one's easy: It's double the size of a float.



 Sep 01 2010



 next sibling parent  so <so so.do>  writes:


 Float (short for "floating point"): The decimal point can "float" around  
 as
 the value changes (not a literal use of "float", but there's nothing  
 wrong
 with metaphoric uses of words, even in ordinary speech). This type is  
 named
 in contrast to the fixed-point arithmetic that was often used as an
 old-school optimization (where the decimal point was always at a fixed
 location, for example, the high 16-bits may have been the whole-number  
 part,
 and the low 16-bits may have been the decimal part).

 Double: This one's easy: It's double the size of a float.


I know what they are, but at the same time was expecting you to get the  
point :)

When you need a compile-time type in C/C++ mostly you don't need a type,  
just :
enum { value = 10 }; // Also, this is suggested over const

Coming from C/C++ enum constants are pretty straightforward as  
compile-time constants.
And please, it is only 4 letters. (In case you missed, they are e, n, u,  
m. They are the 4 best looking
characters on every editor!)

This reminds me the "retro" case, where most argue against and making up  
names such like reverseAndSomeOtherUglyNonsense.
Anyone here got trouble understanding what "enum" is and what it does? No,  
It wasn't the case in retro either.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Sep 01 2010



prev sibling  parent reply so <so so.do>  writes:


 Float (short for "floating point"): The decimal point can "float" around  
 as
 the value changes (not a literal use of "float", but there's nothing  
 wrong
 with metaphoric uses of words, even in ordinary speech). This type is  
 named
 in contrast to the fixed-point arithmetic that was often used as an
 old-school optimization (where the decimal point was always at a fixed
 location, for example, the high 16-bits may have been the whole-number  
 part,
 and the low 16-bits may have been the decimal part).

 Double: This one's easy: It's double the size of a float.


If you throw "2.7f" on a water, does it float or you need to multiply with  
pi first?
Why don't we change double to hmm... doubleTheSizeOfFloat? Lets test it!

-
manifest doubleTheSizeOfFloat pi=3.14;
doubleTheSizeOfFloat f=2.7;
if(!floats(f))
   multiplyFirstOneWithTheSecondAndAssignToTheFirstParameter(f, pi); //  
that was the java operator overloading case? Yeh fundamental type but  
still it is funny!

-
enum pi=3.14;
double f=2.7;
if(!floats(f))
   f *= pi;

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Sep 01 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"so" <so so.do> wrote in message news:op.vidgxic47dtt59 so-pc...

 Float (short for "floating point"): The decimal point can "float" around 
 as
 the value changes (not a literal use of "float", but there's nothing 
 wrong
 with metaphoric uses of words, even in ordinary speech). This type is 
 named
 in contrast to the fixed-point arithmetic that was often used as an
 old-school optimization (where the decimal point was always at a fixed
 location, for example, the high 16-bits may have been the whole-number 
 part,
 and the low 16-bits may have been the decimal part).

 Double: This one's easy: It's double the size of a float.


 If you throw "2.7f" on a water, does it float or you need to multiply with 
 pi first?


Like I said, "metaphor". By contrast there's no basis for a metaphor between 
"enumeration" and manifest constants.


 Why don't we change double to hmm... doubleTheSizeOfFloat? Lets test it!


Please don't go using strawmen. No one ever said anything about 
abbreviations being bad.



 Sep 01 2010



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:mailman.26.1283301521.858.digitalmars-d puremagic.com...

 Then there still is the consistency-issue (anon. enums are treated 
 differently then named enums).


Anon. enums *are* fundamentally different from named enums. It's already 
inconsistent.



 Aug 31 2010



prev sibling next sibling parent reply Kagamin <spam here.lot>  writes:


bearophile Wrote:


But enums are not integers


??
Where did you get it?



 Sep 01 2010



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Kagamin:


But enums are not integers


 
 ??
 Where did you get it?


The whole point of this discussion about my enhancement request 3999 is to turn
a certain subset of enums into "not integers" (or "not bytes", "not longs",
etc).

Bye,
bearophile



 Sep 01 2010



prev sibling next sibling parent  Jonathan M Davis <jmdavisprog gmail.com>  writes:


On Wednesday, September 01, 2010 13:53:51 Andrej Mitrovic wrote:

 I thought to!string(Enum) already does this? This was the example I
 posted in bug report 4261:
 
 import std.conv : to;
 import std.stdio: writeln;
 void main()
 {
     enum Foo { Zero, One }
     Foo f = Foo.One;
     writeln(to!string(f));
 }
 
 Prints: One


Well, like I said, it never occurred to me that you even could print enums as 
strings in D, so I don't know how it's typically done. However, if it's as 
simple as that, I don't really see what the problem is. Sure, it would be nice 
if they printed as strings by default rather than the generally useless base 
type of int or whatever, but using to!string like that is quite straightforward.

- Jonathan M Davis



 Sep 01 2010



prev sibling next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


Steven Schveighoffer:


 enum myBits
 {
     flag1 = 1;
     flag2 = 2;
     flag3 = 4;
 }
 
 void fn(int flags);
 
 fn(myBits.flag1 | myBits.flag2);
 
 That was the one case where I really like the implicit conversion.


Thank you for that important use case. enum is used for three different things:
compile-time constants, a sequence of separated symbols, and a group of flags
that may be grouped.


flags, and documents that an enum is indeed a flags set.

Recently I have proposed to add to Phobos something similar to a
std.bitmanip.bitfields that builds a flag set (the powers of two are set
automatically, you just give the flag names. It may also add a first dummy flag
with value zero). Probably it's not too much hard to do.

The problem is that such (hypotetically named) std.bitmanip.flagset defines
what the language/compiler sees as a normal enum, so it has to share its
features with normal enums. In C++0x you don't have this problem, because you
use "enum" to define flags and "enum class" to define the strongly typed
sequence of symbols.

Your fn() function doesn't truly accept any int, it accepts only a bitwise
combination of members of myBits. A more strict type system may enforce this.
This is feasible in D if std.bitmanip.flagset returns a struct instead of an
enum. This struct contains just an int and methods to perform bitwise
operations that return a struct of the same type. So the signature becomes void
fn(MyBits flags).


This is an idea:


struct MyBits {
    private alias size_t T;
    static assert(is(T == ubyte) || is(T == ushort) || is(T == uint) ||
                  is(T == ulong) || is(T == size_t));

    private T _bits;
    public enum nothing = MyBits(0);

    private enum uint nflags = 3; // flag1, flag2, flag3
    static assert(nflags <= T.sizeof * 8);

    static if (nflags == (T.sizeof * 8))
        private enum T full = T.max; // because ((1UL << 64) - 1) != ulong.max
    else
        private enum T full = ((cast(T)1) << nflags) - 1;

    public enum flag1 = MyBits((cast(T)1) << 0);
    public enum flag2 = MyBits((cast(T)1) << 1);
    public enum flag3 = MyBits((cast(T)1) << 2);

    this(MyBits other) { this._bits = other._bits; }

    this(T value) { this._bits = value; }

    invariant() {
        assert(!(this._bits & ~full));
    }

    MyBits opUnary(string Op="~")() {
        return MyBits(~this._bits & full);
    }

    MyBits opBinary(string op)(MyBits other) if (op == "|" || op == "&") {
        mixin("return MyBits(this._bits " ~ op ~" other._bits);");
    }
}

//--------------------------
import std.stdio: writeln;

void fn(MyBits flags) {
    writeln(flags._bits);
}

void main() {
    fn(MyBits.flag1 | MyBits.flag2);
    fn(MyBits.flag1 & MyBits.flag2);
    auto f = MyBits.flag1;
    assert(f == MyBits.flag1);
    writeln((1UL << 64) - 1);
}



Given the names "flag1", "flag2", "flag3" (and the optional type T),
std.bitmanip.flagset generates a struct like MyBits (plus few more missing
parts).

-------------------------

Don:


 OTOH if each member has an explicitly defined value, it's reasonable to
 perform logical operations on it.


Thank you for your usually wise point of view.

Bye,
bearophile



 Sep 02 2010



prev sibling  parent  bearophile <bearophileHUGS lycos.com>  writes:


Don:

 That's impossible. That would make interfacing to C a nightmare.


I see.



 By the way, enums which consist of flags frequently have values which 
 have more than one bit set. The case { A=1, B=2, C=4, D=8 } is only a 
 special case.


That indeed happens, but from the code that I have seen the most common case is
the one with powers of two flags. This is why I think it's useful to add the
flagset struct to Phobos, because it avoids/catches some common bugs.



 In the general case, it's not realistic to hope that the compiler could 
 determine which values are valid, and which are not.


Right. But a flagset helps because:
- It gives a very short definition syntax for the common case when flags are
power of two.
- In that case it removes the mistakes in power-of-two flag and the missing
dummy (0) flag.
- The struct invariant is able to catch few runtime bugs because it tests that
the unused bits in the underlying value are always zero.



 But, with my suggestion, simple enums (a list of mutually exclusive 
 values) would become strong enums.


This is better than the current situation. I'd like Walter to give a word on
this thread.

Bye,
bearophile



 Sep 05 2010