Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"

[Andrei Alexandrescu via Digitalmars-d]

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