Regan Heath: > but it seems like it's not quite what we want, we really want > a set of compile time constants.
I meant using the same design strategy. See below. -------------------- Andrei: >In particular, economy of means does not seem to be one of C#'s strengths.< I agree, surely C# is not a compact and orthogonal language. C# devs are aware of this, you can see it from the very low number of features they have added to C#4. >Who are "they"?< Almost everyone that posts on this newsgroup :-) I put myself in the group too, because I am not expert of C# and many times in the past I have "invented" things for D that later I have found in C#, sometimes with a design better than mine. >Why does a mechanism that allows creating bitfields, custom enums, flags, >custom-base literals, and more, feel hackish, whereas dumping a wheelbarrow of >narrow-usefulness features with every release while still failing to address >major problems (concurrency, immutability) feels not?< I agree with you that too many features turn a language in a ball of mud. On the other hand an excess of abstraction or relying too much on the composition of elementary parts makes writing code like solving a Rubik cube (see Scheme language or your "find" algorithm in Phobos2). In this case it may be acceptable to use compile-time strings to create a flags-like struct, I'd like to write it :-) But I am not sure it's the best solution. I have to judge when it's done. Maybe in this case the C# solution is the best. The main of my precedent post was that you can't allow arithmetic operations on enums just because you may want to use them as bit flags. They are two different purposes. In this case C# tells the two usages apart in a clear way, instead of mudding them together. If the purpose is clear and well defined, and the usage is safe, I think programmers don't have too much hard time remembering the purpose of fields. That's why I don't think introducing "many" keywords is bad, it's better to use something like "autoconst" than using "inout" to save a keyword, that's unrelated to the its purpose. The lesson given by the success of large languages like C# is that programmers are able to remember and use many things if their purpose is clear and def! ined in a semantically tidy way. (I think the current design decisions of D enums are not the best ones.) The code of std.bitmanip.bitfields is hard or impossible to understand, to read, to fix, to modify, to improve. Compile-time strings used as macros are acceptable for one-liners, but your (nicely safe!) bitfields shows that it's not fit when you want to push it to that complexity level. Bye, bearophile
