Flag proposal

Jonathan M Davis jmdavisProg at gmx.com
Sat Jun 11 20:54:02 PDT 2011


On 2011-06-11 20:50, Jonathan M Davis wrote:
> 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.

Yikes! How did that get posted three times?! I wonder if my mail client is on 
the fritz...

- Jonathan M Davis


More information about the Digitalmars-d mailing list