On 2011-06-10 15:54, Andrei Alexandrescu wrote: > On 6/10/11 5:14 PM, Steven Schveighoffer wrote: > > On Fri, 10 Jun 2011 16:21:59 -0400, Andrei Alexandrescu > > > > <seewebsiteforem...@erdani.org> wrote: > >> There is general agreement (which includes myself) that a language > >> feature is nicer than Flag, > > > > Yes. > > > >> and that Flag is nicer than the current state of affairs. > > > > No. Flag!"KeepTerminator".yes is much worse than KeepTerminator.yes. And > > Flag!"KeepTerminator" keepTerminator is just, horrendous, in > > documentation *or* source. > > https://github.com/andralex/phobos/commit/84c75336a4ef04b4c3b1924d7ac9329e7 > 44ab8e7 > > > If the rote creation of boolean enums is a problem, why not a mixin? > > > > template Flag(string name) > > { > > mixin("enum " ~ name ~ " : bool { no = false, yes = true }"); > > } > > > > mixin Flag!"KeepTerminator"; > > Because you still need to define it separately from use.
What I want to know is what you want to do with such enums where it's actually _desirable_ that they be defined separately from use. A prime example of this is std.datetime's AllowDayOverflow. It's used by several functions, and by having it explicitly defined separately, it can be appropriately documented in one place rather than having to explain it for every function that uses it. I really think that it _should_ be defined separately. But if it is defined separately, then I don't see how it could work with the Flag template. Even if we go with the improved yes and no templates that you just added (which are definitely an improvement over naked Flag), they don't work with a yes/no enum which is defined separately. This means that you'll have AllowDayOverflow.yes and AllowDayOverflow.no instead of yes!"AllowDayOverflow" and no!"AllowDayOverflow". That's not necessarily a bad thing, since the enum _is_ defined differently, but if the common idiom is to use yes!"enumName" and no!"enumName", then the yes/no enums which are actually defined separately won't match. Is that acceptable, or is there actually a reasonable way to make the yes and no templates work with non-Flag enums (perhaps by having it first check whether enumName.yes compiles before trying Flag!"enumName")? - Jonathan M Davis