Flag proposal

Jonathan M Davis jmdavisProg at gmx.com
Sat Jun 11 20:50:18 PDT 2011


On 2011-06-11 20:44, Andrei Alexandrescu wrote:
> On 06/11/2011 04:42 PM, Jonathan M Davis wrote:
> > On 2011-06-11 14:32, David Nadlinger wrote:
> >> On 6/11/11 11:20 PM, Jonathan M Davis wrote:
> >>> 1. Programmers following this idiom (including the Phobos devs) end up
> >>> creating enums with yes and no values and are effectively identical to
> >>> other enums except for their names. So, we end up with a fair bit of
> >>> boilerplate code just to pass a strict boolean value.
> >> 
> >> s/fair/tiny/, imho:
> >> 
> >> ---
> >> /// ditto.
> >> enum SomeFlag { enable, disable }
> >> ---
> > 
> > It's a fair bit only insomuch as the same code is duplicated in several
> > places. The code itself in each instance is small. But if you do that
> > enough times, it adds up. Whether it's enough to matter is debatable,
> > but there is definitely boilerplate code there which could be reduced.
> > 
> > - Jonathan M Davis
> 
> It's the namespace pollution and the non-self-containedness of the
> function that's most troublesome. Also see Steve's point about methods.
> It's just untenable - to use the idiom with a class/struct method, you
> need to go all the way _outside_ of it an plant a symbol there.
> 
> What I find most interesting is that the lack of strong counterarguments
> has not stood in the way of a strong emotional response. This mood has
> made it difficult for exchange of rational arguments. Funny thing is,
> the change is tiny.
> 
> "Here, I'll add a handful of yes/no enums here and there in the standard
> library, just to help some algorithms. More to come."
> 
> "Yeah, sure, whatevs."
> 
> "Here, there's a way to define them once so we don't need to define them
> everywhere."
> 
> "Gaaaaaaaaaaaaaa!!!"

Honestly, at this point, I think that your proposal is pretty good, but I'm 
not sure that it's worth the degradation in error messages that the added 
templatization causes. But for a lot of people, I think that it's simply a 
combination of them not liking the yes/no enum idiom in the first place and/or 
feeling like what they really want is named parameters and that this really 
should be solved by named parameters. So, they don't like it. Personally, I'm 
a bit ambivalent towards yes/no enums, but I'm fine with having them. At this 
point, I'm just concerned about the worse error messages that the use of Flag 
will create and whether that pain is worth the added benefit that Flag brings.

- Jonathan M Davis


More information about the Digitalmars-d mailing list