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