On 2011-06-10 09:15, Andrei Alexandrescu wrote: > https://github.com/D-Programming-Language/phobos/pull/94 > > Discuss!
Okay. Let's see if I can summarize this. Andrei thinks that have a categorized boolean type which is explicit about what it's used for is valuable. So, for instance, std.algorithm.until takes OpenRight.yes and OpenRight.no rather than bool so that it's explicit to the caller what the boolean value indicates and so that you don't accidentally pass a bool which means something else entirely to until. This currently requires declaring a separate enum with yes and no values for every function that does this with the occasional function which can reuse such an enum from another function, because it needs a boolean value for exactly the same thing. Andrei therefore have 2 problems with the status quo: 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. 2. The documentation for these yes/no enums generally really should be with the function that they're using but ends up on the enum itself or in both places. Ideally, it would just go with the function. So, Andrei created the Flag template in an attempt to do 3 things: 1. Be able to create the yes/no enum just by declaring the type of the function parameter - you eliminate boilerplate code. 2. The documentation is then clearly with the function that the yes/no enum goes with (it has nowhere else to go). 3. It promotes the yes/no idiom in a manner than seeing Flag!"enumName" as the type makes it immediately clear what the type in question is trying to do, and no one feels the need to go looking for the documentation for the enum because the use of the Flag idiom makes it clear what the type is. The complaints about this generally seem to be one of these: 1. Dislike of the yes/no enum idiom in the first place. Regardless of how Flag does it, it's a problem, because it's promoting an idiom that the poster dislikes in the first place. 2. Flag!"enumName".yes and Flag!"enumName".no are ugly. 3. The use of a template such as Flag results in ugly error messages when it's mistyped. EnumName.yes gets _much_ better errors when mistyped than Flag!"enumName".yes. 4. Flag is seen as a narrow attempt at named arguments which would be far better served by actually implementing named arguments. Andrei's response to each of these in turn is: 1. He argues for the yes/no enum idiom, citing issues with naked bool values and lack of clarity in code - how it saves you from having to look at the documentation to figure out what a particular boolean value means. It's essentially the same arguments he's made for the idiom ever since it was introduced into Phobos. 2. He proposed a template wrapper which would allow you to type yes!"enumName" and no!"enumName" instead of the full Flag!"enumName".yes and Flag!"enumName".no. Some people feel that this resolves complaint #2. Others think that it's still quite ugly. 3. He essentially says that the compiler's error messages for templates need to be improved. It's an inherent problem with templates. 4. He's not trying to solve anything with named arguments. He's trying to solve a much narrower problem of naked bool values being relatively meaningless for many function arguments and error-prone when you pass a boolean value which meant something else entirely. yes/no enums solve that specific problem. Named arguments would be a change to the language at a time when we should be looking at doing as much with the language as possible rather than looking to add new features to it. Features which solve restrictions and intrinsic problems in the language need to be looked at, but those which could be solved by using the existing language and creating a library-based solution should be first explored as library solutions. Would you say that this is a fair summary of this debate so far? - Jonathan M Davis
