Flag proposal

[Andrei Alexandrescu]

On 6/11/11 11:56 AM, Michel Fortin wrote:
> On 2011-06-11 12:01:33 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 6/11/11 10:40 AM, Michel Fortin wrote:
>>> On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> said:
>>>> For representing categorical data with small sets, programming
>>>> languages use enumerated types. This is because in a small set you can
>>>> actually give name each element. That way you have a separate type for
>>>> the categorical data so you can enjoy good type checking. The mistake
>>>> I believe you are making is the conflation of a categorical data with
>>>> two categories with an unstructured Boolean. By making that conflation
>>>> you lose the advantages of good typechecking in one fell swoop.
>>>
>>> I think you're misinterpreting. I don't like yes/no enums because I
>>> don't find the value names meaningful, but I'm perfectly fine with
>>> two-element enums if they are properly named.
>>
>> What is meaningless about OpenRight.yes?
>
> Choosing between "yes" and "no" is not meaningful. I'd rather choose
> between "open" and "closed".

I don't see how "OpenRight.yes" is meaningless and "Openness.right" is 
meaningful.

> Of course you'd have to pick a more fitting
> name for the enum,

Name one.

> preferably one that could work for all bounds, not
> just the right one to make the category more useful.

Again, the charter of that particular category is only "open to the right".

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.

Alright, so we have

void topNIndex(
     alias less = "a < b",
     SwapStrategy ss = SwapStrategy.unstable,
     Range, RangeIndex)(Range r, RangeIndex index,
         SortOutput sorted = SortOutput.no);

With Flag in tow, you'd delete SortOutput and you'd replace the 
definition with:

void topNIndex(
     alias less = "a < b",
     SwapStrategy ss = SwapStrategy.unstable,
     Range, RangeIndex)(Range r, RangeIndex index,
         Flag!"sortOutput" sorted = No.sortOutput);

Call:

auto a = [ 1, 2, 3 ];
topNIndex(a, Yes.sortOutput);

I understand you find the above meaningless and would advocate using a 
bool, which means:

topNIndex(a, true);

which would have even me running to the manual, and I wrote the darn thing.

With named parameters, we'd have something along the lines of:

topNIndex(a, sortOutput : true);

which is nice, but not present in the language (and I can tell after 
talking to Walter it won't be anytime soon).

With your choice of meaningful/less, you'd have something like:

enum HowToOutput { unsorted, sorted }
topNIndex(a, HowToOutput.sorted);

which is pretty much the same thing as yes/no, just more convoluted and 
less systematic. I mean you can't impose to yourself to choose any names 
except "yes" and "no" on account of them being meaningless.


Andrei