On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:
> On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:
>> * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful.
>
> I disagree. Making an alias means the user does not have to import std.typecons in their code, and as a purely subjective measure, ReplaceArrayWithPointer.Yes looks better than Flag!"replaceArrayWithPointer".Yes.

Me too. @Andrei, what exactly is wrong with the alias?

On Friday, 22 January 2016 at 14:48:47 UTC, Marc Schütz wrote:
> On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:
>> On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:
>>> * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful.
>>
>> I disagree. Making an alias means the user does not have to import std.typecons in their code, and as a purely subjective measure, ReplaceArrayWithPointer.Yes looks better than Flag!"replaceArrayWithPointer".Yes.
>
> Me too. @Andrei, what exactly is wrong with the alias?

I'd like to know this too considering the official documentation used it until this discussion was started.

On 2016-01-21 20:31, Andrei Alexandrescu wrote:
> The correct idiom involving Flag is:
>
> * Use the name Flag!"frob" for the type of the flag
>
> * Use Yes.frob and No.frob for the flag values
>
> * Do NOT alias Flag!"frob" to a new name. This is unnecessary,
> unhelpful, and wasteful.
>
> Can somebody please change the respective code in std.experimental.ndslice?

Can we just implement a basic form of named parameters that remove the ugly workaround that Flag is.

void a(int x);
a(x: 3); // error, cannot be called with named parameters

void b(int x:);
b(3); // ok
b(x: 4); // ok

void c(int x:, int y:);
c(x: 3, y: 4); // ok
c(y: 4, x: 4); // error, named parameters out of order

The first error is to avoid making parameter names public API by default. The second error is to not change how overloading works.

-- 
/Jacob Carlborg

On Friday, 22 January 2016 at 17:09:01 UTC, Jacob Carlborg wrote:
> On 2016-01-21 20:31, Andrei Alexandrescu wrote:
>> [...]
>
> Can we just implement a basic form of named parameters that remove the ugly workaround that Flag is.
>
> void a(int x);
> a(x: 3); // error, cannot be called with named parameters
>
> void b(int x:);
> b(3); // ok
> b(x: 4); // ok
>
> void c(int x:, int y:);
> c(x: 3, y: 4); // ok
> c(y: 4, x: 4); // error, named parameters out of order
>
> The first error is to avoid making parameter names public API by default. The second error is to not change how overloading works.

DIP please! --Ilya

On 2016-01-22 23:00, Ilya wrote:

> DIP please! --Ilya

http://forum.dlang.org/post/n8024o$dlj$1@digitalmars.com

-- 
/Jacob Carlborg

On 01/22/2016 09:48 AM, Marc Schütz wrote:
> On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:
>> On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:
>>> * Do NOT alias Flag!"frob" to a new name. This is unnecessary,
>>> unhelpful, and wasteful.
>>
>> I disagree. Making an alias means the user does not have to import
>> std.typecons in their code, and as a purely subjective measure,
>> ReplaceArrayWithPointer.Yes looks better than
>> Flag!"replaceArrayWithPointer".Yes.
>
> Me too. @Andrei, what exactly is wrong with the alias?

Consider (taken from allocator):

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
    size_t minSize, size_t maxSize = minSize,
    Flag!"adaptive" adaptive = No.adaptive);

As an aside, this idiom should crystallize to:

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
    size_t minSize, size_t maxSize = minSize,
    Flag!"adaptive" flag = No.adaptive);

i.e. the name of the flag adds no information in neither declaration, definition, nor use. Just call it "flag", "flag1", "flag2" etc.

The alternative is (which is already present in parts of Phobos, e.g. std.stdio.KeepTerminator):

/**
... doc for AdaptiveFreeList, must explain that it is used by FreeList which HAS NOT YET BEEN DEFINED ...
*/
alias FreeListIsAdaptive = Flag!"adaptive";

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
    size_t minSize, size_t maxSize = minSize,
    FreeListIsAdaptive adaptive = FreeListIsAdaptive.no);

The latter version is more conventional - it's the way things are done in other languages (define an enum with yes/no, use it etc), and uses Flag just as an implementation device. I do agree the familiarity and conventionality argument has some strength to it. Other than that, the latter version has no advantage over the first, only disadvantages:

* In the first version it suffices to look at one declaration to understand everything: there is a yes/no flag related to adaptivity, and by default it's "no". In the second version you need to look in two places.

* The name "FreeListIsAdaptive" is introduced over the entire scope and must of course be public so the client can use it, yet only FreeList is using it.

* The name "FreeListIsAdaptive" by itself does not indicate it's a yes/no flag. It may be really any type so a look at the definition or documentation is necessary. The name Flag!"adaptive" is properly positioned from the get-go.

Flag is a very nice D idiom. I admit it took me a while to realize it and its implication, and I felt odd designing APIs with it in the beginning, coming from a habit to define my own aliases for such things. But the matter of fact is it's a very simple and expressive tool, and there's no necessity to blunt it just to use it the old way.


Andrei