Flag proposal

[Jonathan M Davis]

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