Flag proposal

Jonathan M Davis jmdavisProg at gmx.com
Sat Jun 11 20:45:05 PDT 2011


On 2011-06-11 20:27, Andrei Alexandrescu wrote:
> On 06/11/2011 03:52 PM, Nick Sabalausky wrote:
> > "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
> > news:it07ni$1pvj$1 at digitalmars.com...
> > 
> >> Anyway, that was the first thing "grep yes std/*" found. Let's see the
> >> next one:
> >> 
> >> /**
> >> Specifies whether the output of certain algorithm is desired in sorted
> >> format.
> >> 
> >>   */
> >> 
> >> enum SortOutput {
> >> 
> >>      no,  /// Don't sort output
> >>      yes, /// Sort output
> >> 
> >> }
> >> 
> >> This already is very unpleasant because "certain" is as imprecise as it
> >> gets. Plus one for Flag, I hope you agree.
> > 
> > Flag -= 1
> > s/output of certain algorithm/output of an algorithm/ += 1
> > 
> > That one-word doc change makes it all perfectly clear.
> 
> Not at all. The typo in the original text must have confused you: it
> should be "certain algorithms" because SortOutput is used in four
> distinct algorithms (one of which has two overloads). Grep std/algorithm.d.
> 
> Flag += 2
> 
> > Also, since you're in favor of Flag, I think you'd agree with me that the
> > doc comments on the "no" and "yes" values are unnecessary and can be
> > ditched. Which makes the whole idiom this:
> > 
> > enum SortOutput { no, yes }
> 
> This exact kind of argument has been made in 1995 in favor of STL
> algorithms that require defining a struct outside the current context.
> The cost of adding one extra symbol turned out to be a fair amount more
> unpleasant than it was initially though.
> 
> Assessing that the boilerplate in this case is one line would be missing
> that important aspect.

Yes, though there is a distinct difference between having to create a functor 
elswhere to just to call an STL function and creating an extra enum next to 
your function definition for one of its parameters. The parameter issue is far 
smaller IMHO. It only comes up when defining functions, and particularly if we 
created a mixin for creating such an enum, the overhead would be fairly 
minimal - certainly far less than creating a functor for every call to an STL 
algorithm function (which pratically destroys the usefulness of the STL's 
algorithms for most people). So, I don't think that the cost involved is 
altogether comparable. However, you do bring up a very valid point. Flag 
definitely lowers the bar for the usage of such enums.

Ultimately, my main concern with using Flag like this is the error messages. 
Given the templates involved, I'd expect them to be pretty bad. D's template 
error messages are certainly better than C++'s (primarily thanks to template 
constraints), but they're still pretty bad - especially for newbies - and this 
particular use case effectively is simplifying the library developer's life 
slightly at the cost of nastier error messages for everyone who mistypes one 
of these enums. So, we save pain in one area and move it over to another which 
arguably has a higher impact. And I'm just not sure whether that's worth it or 
not. The fact that you've gotten to Yes.EnumName and eliminated all of the 
obvious template stuff from the user's perspective makes the code much 
cleaner, and it's fine as long as they don't have any typos, but the 
difference between EnumName.yes and Yes.EnumName for the user is pretty much 
nonexistant except for the fact that Yes.EnumName will have worse error 
messages. So, from the user's perspective, the situation is worse.

I don't know. I think that this proposal has reached the point where it might 
be reasonable to include it, but I just don't know if the gain in development 
is worth the pain for everyone who uses the functions which have Flag enums. 
If the error messages weren't worse, then it wouldn't be a problem, but as 
soon as you include templates, the error messages are pretty much always 
significantly worse. If there were a significant gain from this proposal, then 
I'd say that it would be worth it, but the gain seems pretty minor to me. So, 
I just don't know.

- Jonathan M Davis


More information about the Digitalmars-d mailing list