A basic version of a compile-time enum-based bit flags: import std.traits: isUnsigned; import std.string: split; import std.conv: text; import std.algorithm: canFind; bool isReservedWord(in string w) { string[] reservedWords = "abstract alias align asm assert auto body bool break byte case cast catch cdouble cent cfloat char class const continue creal dchar debug default delegate delete deprecated do double else enum export extern false final finally float for foreach foreach_reverse function goto idouble if ifloat immutable import in inout int interface invariant ireal is lazy long macro mixin module new nothrow null out override package pragma private protected public pure real ref return scope shared short static struct super switch synchronized template this throw true try typedef typeid typeof ubyte ucent uint ulong union unittest ushort version void volatile wchar while with __FILE__ __LINE__ __gshared __thread __traits".split(); return canFind(reservedWords, w); } string bitFlags(BaseType)(string enumName, string enumItems) if (isUnsigned!BaseType) { assert (enumItems.split().length < (BaseType.sizeof * 8), text("BaseType (", BaseType.stringof, ") doesn't have enough bits to represent all the enumItems.")); string result = text("enum ", enumName, " : ", BaseType.stringof, " {\n"); foreach (i, flag; enumItems.split()) { assert(!isReservedWord(flag), text("enum '", flag, "' is a D keyword.")); result ~= text(" ", flag, " = (1 << ", i, "),\n"); } return result ~ "}"; } // example usage: mixin(bitFlags!size_t("MyEnum", "A B C D")); //mixin(bitFlags!ulong("MyEnum", "A B C D")); // writeln bug void main() { import std.stdio; writeln(MyEnum.C); } This code lacks many handy features, including safety features when you combine flags with MyEnum.A|MyEnum.B, but for a basic usage, if you have many flags, it seems better than not using it. Note: in this simple implementation the first enum (here MyENum.A) equals to 2^0 = 1, so there is no enum for zero. Change this if you want. I'd probably like a function like isReservedWord() too in Phobos. Here the reservedWords array is not static because I need to call isReservedWord() at compile time too. Even if flags are sometimes more complex than the ones this function generates, I think something like this (but improved) is useful in Phobos for the common basic situations.
For the C# [Flags] attribute see: http://msdn.microsoft.com/en-us/library/cc138362.aspx http://msdn.microsoft.com/en-us/library/system.flagsattribute.aspx In D enums EnumBaseType defaults to int: http://www.d-programming-language.org/enum.html but for powers of two bit flags I think using an unsigned type is saner, so for bitFlags I have used uint as default type. Follows a bit improved version, it always contains a "None" member too, represented with 0: import std.traits: isUnsigned; import std.string: split; import std.conv: text; import std.algorithm: canFind; bool isReservedWord(in string w) { string[] reservedWords = "abstract alias align asm assert auto body bool break byte case cast catch cdouble cent cfloat char class const continue creal dchar debug default delegate delete deprecated do double else enum export extern false final finally float for foreach foreach_reverse function goto idouble if ifloat immutable import in inout int interface invariant ireal is lazy long macro mixin module new nothrow null out override package pragma private protected public pure real ref return scope shared short static struct super switch synchronized template this throw true try typedef typeid typeof ubyte ucent uint ulong union unittest ushort version void volatile wchar while with __FILE__ __LINE__ __gshared __thread __traits".split(); return canFind(reservedWords, w); } string bitFlags(BaseType=uint)(string enumName, string enumItems) if (isUnsigned!BaseType) { assert ((enumItems.split().length + 1) < (BaseType.sizeof * 8), text("BaseType (", BaseType.stringof, ") doesn't have enough bits to represent all the enumItems plus None.")); string result = text("enum ", enumName, " : ", BaseType.stringof, " {\n"); result ~= text(" None = 0,\n"); foreach (i, flag; enumItems.split()) { assert(!isReservedWord(flag), text("bitFlags: enum member '", flag, "' is a D keyword.")); result ~= text(" ", flag, " = (1 << ", i, "),\n"); } return result ~ "}"; } // example usages ---------------- mixin(bitFlags!size_t("MyFlags", "A B C D")); //mixin(bitFlags!ulong("MyFlags", "A B C D")); // writeln bug 6892 mixin(bitFlags("Days", "Sunday Monday Tuesday Wednesday Thursday Friday Saturday")); void main() { import std.stdio; writeln(MyFlags.C); import std.traits, std.algorithm; assert(equal(map!text([EnumMembers!MyFlags]), ["None", "A", "B", "C", "D"])); Days meetingDays = Days.Tuesday | Days.Thursday; }
Please use 'none' instead of 'None' (and so on) to follow Phobos naming conventions.
You probably need to turn this into a pull request if you want it reviewed for inclusion in phobos.
I think Delphi has the most convenient implementation of sets. type TWorkDay = (Monday, Tuesday, Wednesday, Thursday, Friday) ; TDaySet = set of TWorkDay; var days : TDaySet; begin days := [Monday, Friday]; days := days + [Tuesday, Thursday] - [Friday]; if Wednesday IN days then ShowMessage('I love Wednesday!') ; It also uses the 2^n binary notation internally. Any proposed solution should add safety as well as the basic set operators. As long as it is still easier to write "set &= ~flag" to remove a flag from a set, it failed its mission. It would be even better if a set type would be allowed in bindings to C code or painlessly converted to it's integer representation with "set.val" or similar. :)
Related NG thread: http://forum.dlang.org/thread/k3soo8$2ast$1@digitalmars.com
See also Issue 8727
A note about syntax: > mixin(bitFlags!size_t("MyFlags", "A B C D")) Wrapping enum code in a mixin template could allow: mixin BitFlags!size_t("A B C D")) MyFlags; Or if D mixin syntax was changed similar to alias assignment syntax: mixin MyFlags = BitFlags!size_t("A B C D"));
(In reply to comment #7) > A note about syntax: > > > mixin(bitFlags!size_t("MyFlags", "A B C D")) > > Wrapping enum code in a mixin template could allow: > > mixin BitFlags!size_t("A B C D")) MyFlags; > > Or if D mixin syntax was changed similar to alias assignment syntax: > > mixin MyFlags = BitFlags!size_t("A B C D")); Is the name "MyFlags" not useful (as shown in the syntax you quote)?
(In reply to comment #8) > Is the name "MyFlags" not useful (as shown in the syntax you quote)? It's fine, I just thought it might be good to take advantage of a mixin identifier (I often forget about that feature). It seems a bit cleaner to me than a string argument, although having mixin assignment syntax would make this clearer. Nice idea BTW. The cleanness is because I like to have identifiers highlighted in the same way rather than have some as strings, so I would prefer to read something like: mixin BitFlags!q{A, B, C, D} MyFlags;
(In reply to comment #9) > although having mixin assignment syntax would make this > clearer. Nice idea BTW. The point of giving it a name in some way (with a string) is because later you can use some trait to ask for its name. I am not suer how important this is. The idea comes from Python namedtuples: >>> from collections import namedtuple >>> Three = namedtuple("Two", "a b") >>> Three(1, 2) Two(a=1, b=2)
(In reply to comment #10) > The cleanness is because I like to have identifiers highlighted in the same way > rather than have some as strings, so I would prefer to read something like: > > mixin BitFlags!q{A, B, C, D} MyFlags; Is your version using a function like isReservedWord() I have shown in the first posts here?
(In reply to bearophile_hugs from comment #11) > (In reply to comment #10) > > mixin BitFlags!q{A, B, C, D} MyFlags; A better reason for this syntax is that is gives a name for ddoc to use for documentation. Unfortunately the members can't be documented though. > Is your version using a function like isReservedWord() I have shown in the > first posts here? I haven't actually implemented it, it could do.
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/9916 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB