A fair amount of code in std uses this idiom:

enum SomeOption { no, yes }

void someFunction(...parms..., SomeOption, ...more_parms...) { ... }

SomeOption is really a Boolean but replaces the unhelpful call syntax someFunction(...args..., false, ...more_args...) with the self-documenting ...args..., SomeOption,no, ...more_args...).

The liabilities of using Booleans for describing flags have been documented in several places, including McConnell's Code Complete. I think the idiom above is a good replacement.

One issue I have with it is that it requires separate definition and documentation. Usually the documentation awkwardly states "This type is really an option for someFunction, which you haven't seen yet. Skip this for now, then get back, and you'll understand." Moving the enum to after the function is possible but equally confusing.

So I was thinking of planting a simple template in std.typecons:

template YesOrNo(string name)
{
    mixin("enum "~name~" : bool { no, yes }");
}

That way, the definition of the function needs no separately-defined is self-documenting:

void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }

The question is to what extent this would mark progress and fostering structured use of this idiom, versus just confusing beginners and adding deadweight to Phobos.



Andrei

It looks like an awkward workaround for that feature called named arguments.

On 11.04.2011 16:53, Andrei Alexandrescu wrote:
> A fair amount of code in std uses this idiom:
> 
> enum SomeOption { no, yes }
> 
> void someFunction(...parms..., SomeOption, ...more_parms...) { ... }
> 
> SomeOption is really a Boolean but replaces the unhelpful call syntax someFunction(...args..., false, ...more_args...) with the self-documenting ...args..., SomeOption,no, ...more_args...).
> 
> The liabilities of using Booleans for describing flags have been documented in several places, including McConnell's Code Complete. I think the idiom above is a good replacement.
> 
> One issue I have with it is that it requires separate definition and documentation. Usually the documentation awkwardly states "This type is really an option for someFunction, which you haven't seen yet. Skip this for now, then get back, and you'll understand." Moving the enum to after the function is possible but equally confusing.
> 
> So I was thinking of planting a simple template in std.typecons:
> 
> template YesOrNo(string name)
> {
>     mixin("enum "~name~" : bool { no, yes }");
> }
> 
> That way, the definition of the function needs no separately-defined is self-documenting:
> 
> void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }
> 
> The question is to what extent this would mark progress and fostering structured use of this idiom, versus just confusing beginners and adding deadweight to Phobos.
> 
> 
> 
> Andrei

Named parameters fix this without the need for workarounds.

someFunction(...parms..., someOption=>true, ...more parms....);

On 11.04.2011 18:53, Andrei Alexandrescu wrote:
> A fair amount of code in std uses this idiom:
>
> enum SomeOption { no, yes }
>
> void someFunction(...parms..., SomeOption, ...more_parms...) { ... }
>
> SomeOption is really a Boolean but replaces the unhelpful call syntax someFunction(...args..., false, ...more_args...) with the self-documenting ...args..., SomeOption,no, ...more_args...).
>
> The liabilities of using Booleans for describing flags have been documented in several places, including McConnell's Code Complete. I think the idiom above is a good replacement.
>
> One issue I have with it is that it requires separate definition and documentation. Usually the documentation awkwardly states "This type is really an option for someFunction, which you haven't seen yet. Skip this for now, then get back, and you'll understand." Moving the enum to after the function is possible but equally confusing.
>
> So I was thinking of planting a simple template in std.typecons:
>
> template YesOrNo(string name)
> {
>     mixin("enum "~name~" : bool { no, yes }");
> }
>
> That way, the definition of the function needs no separately-defined is self-documenting:
>
> void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }
>
> The question is to what extent this would mark progress and fostering structured use of this idiom, versus just confusing beginners and adding deadweight to Phobos.
>
>
Well, it's workaround but an interesting one.
I presume the user side remains intact and it's just enum declaration that got inculcated into the someFunction declaration, right? (I suspect some folks on the  NG might be puzzled by it so I'll try to clarify some points)
Like:
someFunction(...,SomeOption.yes,...);

Then yes it marks certain progress, and I like it. BTW double definition is also nicely solved (i.e. it would be the same template instance). YesOrNo!"Direction" would be the same for all function dealing with "Direction" parameter.

Then to save lives of novices reading API docs, we should have some nice short memo about this idiom on the language page or even in the Phobos module listing "common idioms" if we have lots of them, plus links to it everywhere applicable.

-- 
Dmitry Olshansky

Andrej Mitrovic wrote:
> It looks like an awkward workaround for that feature called named arguments.

Named arguments aren't a part of standard D now, nor does it look likely they will be for many years.

We've gotta look at the here and now to make decisions; focus on what we have rather than what we don't have.

They aren't a part of D as long as we try to avoid them with workarounds that make functions look like crap.

On Apr 11, 11 23:27, Adam D. Ruppe wrote:
> Andrej Mitrovic wrote:
>> It looks like an awkward workaround for that feature called named
>> arguments.
>
> Named arguments aren't a part of standard D now, nor does it look
> likely they will be for many years.
>
> We've gotta look at the here and now to make decisions; focus
> on what we have rather than what we don't have.

Well the same argument was used to reject assertPred in favor of an improved assert which we still don't have (issue 5547). (Though changing assert's output doesn't change the D spec, while adding named arguments do, and the D2 spec is frozen.)

On 4/11/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> template YesOrNo(string name)
> {
>      mixin("enum "~name~" : bool { no, yes }");
> }
>
> void someFunction(YesOrNo!"SomeOption") { }

How exactly would this work? I can't compile it.

Also, I would rather name this template "choice". Maybe if people got used to this word they would understand it when they see it in the documentation before a function definition. E.g.:

http://codepad.org/9mrL6MOG or if the site is down: https://gist.github.com/913926

Otherwise I have no idea how you can put a new type definition inside of a function parameter and make it public? I'm kind of confused here..

On 11.04.2011 21:13, Andrej Mitrovic wrote:
> On 4/11/11, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> template YesOrNo(string name)
>> {
>>       mixin("enum "~name~" : bool { no, yes }");
>> }
>>
>> void someFunction(YesOrNo!"SomeOption") { }
> How exactly would this work? I can't compile it.
Yeah it's problematic, making it eponymous make function definition work, but at the calling site the party ends...

-- 
Dmitry Olshansky