On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote:
>> For one thing, it avoids the ugly hack which is the Flag template and
>> Yes/No structs.
>>
>> With Flag:
>>

The idiom goes like this.

/// Flag to control whether or not to keep line endings
alias KeepTerminator = Flag!"KeepTerminator";
///
string getLine(KeepTerminator KeepTerminator);

usage:

getLine(KeepTerminator.yes);
or
getLine(Yes.keepTerminator);

So named Boolean flags are a solved problem and are a good improvement over getLine(true) IMO.

On 7/25/15 10:05 AM, Martin Nowak wrote:
> On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote:
>>> For one thing, it avoids the ugly hack which is the Flag template and
>>> Yes/No structs.
>>>
>>> With Flag:
>>>
>
> The idiom goes like this.
>
> /// Flag to control whether or not to keep line endings
> alias KeepTerminator = Flag!"KeepTerminator";
> ///
> string getLine(KeepTerminator KeepTerminator);

I think dispensing with the alias is significantly better. -- Andrei

On 2015-07-25 13:02, Gary Willoughby wrote:

> When showing code don't purposefully make it verbose to strengthen your
> case. Here is how Flag is usually used:

I didn't, I just copied it from the documentation. I never used it myself.

>    getLine(Yes.keepTerminator);
>
> Which is way more readable. Named parameters are not needed!

I disagree, Flag/Yes/No is a gigantic ugly hack.

-- 
/Jacob Carlborg

On 2015-07-25 15:52, Andrei Alexandrescu wrote:

> Replace the second with:
>
> getLine(Yes.keepTerminator);

As I answered in the other post I just copied the example from the documentation.

-- 
/Jacob Carlborg

On 2015-07-25 13:14, Gary Willoughby wrote:

> Here's one:
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

That's ugly and it doesn't work fine, at least not that implementation. It doesn't handle delegate/function parameters.

-- 
/Jacob Carlborg

Am Sat, 25 Jul 2015 14:05:32 +0000
schrieb "Martin Nowak" <code@dawg.eu>:

> On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote:
> >> For one thing, it avoids the ugly hack which is the Flag
> >> template and
> >> Yes/No structs.
> >>
> >> With Flag:
> >>
> 
> The idiom goes like this.
> 
> /// Flag to control whether or not to keep line endings
> alias KeepTerminator = Flag!"KeepTerminator";
> ///
> string getLine(KeepTerminator KeepTerminator);
> 
> usage:
> 
> getLine(KeepTerminator.yes);
> or
> getLine(Yes.keepTerminator);
> 
> So named Boolean flags are a solved problem and are a good improvement over getLine(true) IMO.

Named boolean flags are only one very common special case though. That solution doesn't work that well for integers:

auto w = Window(0, 0, 100, 200);
auto w = Window(x = 0, y = 0, width = 100, height = 200);
//auto w = Window(x.0, y.0, width.100, height.200);

You could introduce new types for X,Y, Width, Height:
auto w = Window(X(0), Y(0), Width(100), Height(200));

It doesn't look that bad. But you'll also have to make sure it converts back to the correct integer types, operator overloading, ... In the end you always introduce new types for something that is one type with named parameters. Having extra types is sometimes the correct thing, sometimes it's not.

On Sat, 25 Jul 2015 17:16:23 +0200
Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Named boolean flags are only one very common special case though. That solution doesn't work that well for integers:
> 
> auto w = Window(0, 0, 100, 200);
> auto w = Window(x = 0, y = 0, width = 100, height = 200);
> //auto w = Window(x.0, y.0, width.100, height.200);
> 
> You could introduce new types for X,Y, Width, Height:
> auto w = Window(X(0), Y(0), Width(100), Height(200));

auto w = Window(Position(0,0), Dimension(100, 200)); // this is what I prefer

but if someone want to be more explicit:

auto w = Window(Position.x(0).y(0), Dimension.width(100).height(200));

On Fri, 24 Jul 2015 14:15:10 +0000, Shammah Chancellor wrote:

> Since D has optional arguments -- why don't we support named parameters?
>  There are extremely handy and work beautifully in languages like C#.

'cause core devs doesn't see much added value in named args. this question was talked to death already. alas.

On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote:
> On 7/25/15 6:32 AM, Jonathan M Davis wrote:
>> If Andrei weren't insisting that we use that idiom everywhere in Phobos,
>> I'd honestly just be using bools and be done with it. It adds some
>> value, but I seriously question that it's worth the extra verbosity. But
>> regardless, I'd hate to see named arguments get added to the language
>> just to clean that mess up.
>
> Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei


Well, somebody was insisting and my PR's wouldn't get pulled without converting to it. Bluntly, I think insisting on using Flag instead of bool is not worth the bother.

On Saturday, 25 July 2015 at 21:14:00 UTC, Walter Bright wrote:
> On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote:
>> On 7/25/15 6:32 AM, Jonathan M Davis wrote:
>>> If Andrei weren't insisting that we use that idiom everywhere in Phobos,
>>> I'd honestly just be using bools and be done with it. It adds some
>>> value, but I seriously question that it's worth the extra verbosity. But
>>> regardless, I'd hate to see named arguments get added to the language
>>> just to clean that mess up.
>>
>> Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei
>
>
> Well, somebody was insisting and my PR's wouldn't get pulled without converting to it. Bluntly, I think insisting on using Flag instead of bool is not worth the bother.

Several of those with commit access seem to have taken a liking to it and insist that it's best practice, and I'm not enthused about it either. Maybe some of those same devs would like to have named arguments as well. I don't know.

- Jonathan M Davis