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!!!"
Andrei
