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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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