Flag proposal

[Jonathan M Davis]

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