www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please change alias ReplaceArrayWithPointer =

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?


Thanks,

Andrei
Jan 21 2016
next sibling parent Ilya <ilyayaroshenko gmail.com> writes:
On Thursday, 21 January 2016 at 19:31:19 UTC, 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?


 Thanks,

 Andrei


OK --Ilya
Jan 21 2016
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 21 January 2016 at 19:31:19 UTC, 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?


 Thanks,

 Andrei


https://github.com/D-Programming-Language/phobos/pull/3946
Jan 21 2016
prev sibling next sibling parent Guillaume Piolat <name.lastname gmail.com> writes:
On Thursday, 21 January 2016 at 19:31:19 UTC, 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?


 Thanks,

 Andrei


Found these guidelines useful:

http://p0nce.github.io/d-idioms/#Using-std.typecons.Flag-like-a-pro
Jan 21 2016
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jan 21 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 21, 2016 at 08:42:17PM +0000, Jack Stouffer via Digitalmars-d 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.


Yeah, and it looks even worse in function signatures, especially when
default arguments are present:

	auto myFunc(T)(T data, Flag!"replaceArrayWithPointer" replaceArrayWithPointer
= Flag!"replaceArrayWithPointer".Yes)
	{ ... }

vs.

	alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer";
	auto myFunc(T)(T data, ReplaceArrayWithPointer replaceArrayWithPointer =
ReplaceArrayWithPointer.Yes)
	{ ... }

Still pretty bad, but at least it's a few characters less.

On a tangential note, default arguments seriously should allow
abbreviated syntax, to prevent the blatant violation of DRY as shown
above:

	auto myFunc(T)(T data, ReplaceArrayWithPointer replaceArrayWithPointer = .Yes)
	{ ... }

Basically, inside a default argument spec, it should be as though the
delcaration were encased in a `with(T) { ... }` block where T is the
type of the argument.

Even better would be a way to not have to type out the variable name
when it is just the type name camelcased, but I haven't thought of a way
of doing this that fits in with D's current syntax just yet.  Some
manner of "eponymous variable", along the same idea as eponymous
templates.


T

-- 
Programming is not just an act of telling a computer what to do: it is also an
act of telling other programmers what you wished the computer to do. Both are
important, and the latter deserves care. -- Andrew Morton
Jan 21 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/21/2016 04:58 PM, H. S. Teoh via Digitalmars-d wrote:

 	auto myFunc(T)(T data, Flag!"replaceArrayWithPointer" replaceArrayWithPointer
= Flag!"replaceArrayWithPointer".Yes)
 	{ ... }


auto myFunc(T)(T data,
     Flag!"replaceArrayWithPointer" flag = Yes.replaceArrayWithPointer)


Andrei
Jan 21 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/21/2016 03:42 PM, 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.


That would be Yes.replaceArrayWithPointer. -- Andrei
Jan 21 2016
prev sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
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?
Jan 22 2016
next sibling parent Zekereth <paul acheronsoft.com> writes:
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.
Jan 22 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 23 2016
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 21 January 2016 at 19:31:19 UTC, 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?


 Thanks,

 Andrei


Perhaps
https://dlang.org/phobos/std_typecons.html#.Flag
should be adjusted. It recommends aliasing.
Jan 21 2016
parent Brad Anderson <eco gnuk.net> writes:
On Thursday, 21 January 2016 at 20:42:56 UTC, jmh530 wrote:

 On Thursday, 21 January 2016 at 19:31:19 UTC, 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?


 Thanks,

 Andrei


 Perhaps
 https://dlang.org/phobos/std_typecons.html#.Flag
 should be adjusted. It recommends aliasing.


https://github.com/D-Programming-Language/phobos/pull/3947
Jan 21 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 22 2016
parent reply Ilya <ilyayaroshenko gmail.com> writes:
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
Jan 22 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-22 23:00, Ilya wrote:


 DIP please! --Ilya


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

-- 
/Jacob Carlborg
Jan 23 2016