Flag proposal

Nick Sabalausky a at a.a
Sat Jun 11 13:52:43 PDT 2011


"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.

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 }

I hadn't noticed this before, but now that I'm actually looking directly at 
that, I don't see how that can be considered "boilerplate", or at least 
enough boilerplate to be worth having a utility template, adding Flag!"..." 
to function signatures in the code and documentation, and the inconsistency 
in changing the user's syntax away from how people expect to use an enum. 
And not only that, but all for the sake of a scenario that you've already 
argued is only rarely encountered. It's a clever use of templates, sure, but 
it's a little too clever for it's own good.





More information about the Digitalmars-d mailing list