www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Wait, what? What is AliasSeq?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
So I thought we were supposed to replace bad names with good names. 
Template arguments are indexable, so "sequence" doesn't quite apply.

What happened? Why are we replacing a crappy term with another crappy term?


Andrei
Jul 07 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.


Apparently Walter was opposed to using List, as that would 
somehow imply "linked list".

  — David
Jul 07 2015
next sibling parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 7 July 2015 at 21:20:54 UTC, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.


 Apparently Walter was opposed to using List, as that would 
 somehow imply "linked list".

  — David


List? I thought we had settled on:
std.meta.Arguments
Jul 07 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/7/15 5:32 PM, Daniel N wrote:

 On Tuesday, 7 July 2015 at 21:20:54 UTC, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names.
 Template arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would somehow
 imply "linked list".


 List? I thought we had settled on:
 std.meta.Arguments


That's what AliasSeq replaced. Arguments was not a very good name IMO. 
See my post on it here: 
http://forum.dlang.org/post/mmhfs1$2jc5$1 digitalmars.com

I'm unsure if Andrei is referring to Arguments or TypeTuple when he says 
"bad names".

-Steve
Jul 07 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2015 2:20 PM, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names. Template
 arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would somehow imply
"linked
 list".


I opposed it because lists are not indexable, and tuples are.
Jul 07 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 7 July 2015 at 22:22:02 UTC, Walter Bright wrote:

 On 7/7/2015 2:20 PM, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template
 arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would 
 somehow imply "linked
 list".


 I opposed it because lists are not indexable, and tuples are.


Linked lists are not indexable, but the term list doesn't 
necessarily imply that it's a linked list. The term list just 
means that you have a group of items in linear order. In fact, if 
you're looking for a generic name for any kind of linear group of 
items (be it a linked list or an array or whatever), I would 
think that list is about as generic as you get. And it says 
nothing about indexability one way or the other.

The core problem here is that the thing that we're trying to name 
here is too much of a hodgepodge of different things to name it 
well. It's not really a tuple, since it's not nestable, but list 
and sequence are kind of odd names too, because in programming, 
with almost everything other than a tuple, you expect all of the 
items in the structure to be the same type, which isn't the case 
here.

Going with Alias seems to solve the problem of whether it holds 
types or values or symbols well. It also deals well with whether 
it's used for arguments or parameters or something else. So, I 
think that going with Alias is a good move.

As for Seq, it's kind of ugly, but if understand that it's 
Sequence, I think that that fits well enough. Personally, I'd 
prefer List over Seq, but if you're vetoing List, then I don't 
know what else we're going to go with. _Nothing_ fits perfectly. 
TypeTuple/AliasSeq/Whatever is just too unique and too much of a 
hodgepodge for any name to really well.

- Jonathan M Davis
Jul 08 2015
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Wednesday, 8 July 2015 at 09:00:58 UTC, Jonathan M Davis wrote:


 Personally, I'd prefer List over Seq,


Given that "list" has meanings other than "linked list" in 
several languages (Python and Racket come to mind), I don't see 
the problem. Perhaps someone with an extensive C or C++ 
background and little experience elsewhere automatically thinks 
"linked list", but someone coming from other languages will not. 
Hell, I don't really have much experiences outside of the 
C-family, but I don't think "linked list" when I see "list".

Furthermore, even the Wikipedia article on Lists makes a 
distinction:

"In computer science, a list or sequence is an abstract data type 
that represents a sequence of values, where the same value may 
occur more than once. An instance of a list is a computer 
representation of the mathematical concept of a finite sequence; 
the (potentially) infinite analog of a list is a stream.[1]:§3.5 
Lists are a basic example of containers, as they contain other 
values. If the same value occurs multiple times, each occurrence 
is considered a distinct item.

The name list is also used for several concrete data structures 
that can be used to implement abstract lists, especially linked 
lists."

Given the nature of the data structure we're talking about, I 
think AliasList is a perfect fit. It's shorter than Sequence (the 
only good alternative I see atm) and List is a whole word, unlike 
Seq. More importantly, it's quite descriptive. Because of the 
baggage surrounding "tuple" in D and the use of "array" to 
already refer to static arrays and dynamic arrays/slices (and a 
data type in Phobos) I don't see either of those as viable 
options.
Jul 08 2015
parent "Mike" <none none.com> writes:
On Wednesday, 8 July 2015 at 09:25:19 UTC, Mike Parker wrote:

 On Wednesday, 8 July 2015 at 09:00:58 UTC, Jonathan M Davis 
 wrote:


 Personally, I'd prefer List over Seq,


 Given that "list" has meanings other than "linked list" in 
 several languages (Python and Racket come to mind), I don't see 
 the problem.



language, and it's indexable and not linked.


 "In computer science, a list or sequence is an abstract data 
 type that represents a sequence of values, where the same value 
 may occur more than once. An instance of a list is a computer 
 representation of the mathematical concept of a finite 
 sequence; the (potentially) infinite analog of a list is a 
 stream.[1]:§3.5 Lists are a basic example of containers, as 
 they contain other values. If the same value occurs multiple 
 times, each occurrence is considered a distinct item.

 The name list is also used for several concrete data structures 
 that can be used to implement abstract lists, especially linked 
 lists."

 Given the nature of the data structure we're talking about, I 
 think AliasList is a perfect fit. It's shorter than Sequence 
 (the only good alternative I see atm) and List is a whole word, 
 unlike Seq. More importantly, it's quite descriptive. Because 
 of the baggage surrounding "tuple" in D and the use of "array" 
 to already refer to static arrays and dynamic arrays/slices 
 (and a data type in Phobos) I don't see either of those as 
 viable options.


Yep, I totally agree. The term "list" largely depends on context, 
but even in the software development domain it can be interpreted 
analagously to "grocery list" or "todo list".  Vetoing AliasList 
leaves us with nothing good.
Jul 08 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2015 2:00 AM, Jonathan M Davis wrote:

 On Tuesday, 7 July 2015 at 22:22:02 UTC, Walter Bright wrote:

 On 7/7/2015 2:20 PM, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names. Template
 arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would somehow imply
"linked
 list".


 I opposed it because lists are not indexable, and tuples are.


 Linked lists are not indexable, but the term list doesn't necessarily imply
that
 it's a linked list.


It does to me, and in common programming usage "list" is often said instead of 
"linked list".



 As for Seq, it's kind of ugly, but if understand that it's Sequence, I think
 that that fits well enough. Personally, I'd prefer List over Seq, but if you're
 vetoing List, then I don't know what else we're going to go with. _Nothing_
fits
 perfectly. TypeTuple/AliasSeq/Whatever is just too unique and too much of a
 hodgepodge for any name to really well.


Which is why I simply picked the name Arguments. The s suffix means plural, and 
doesn't give any preconceived notion about what kind of collection it is. It's
a 
convention I've been using in the dmd source for some time now, and have found 
it to be natural and pleasing.
Jul 08 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 9 July 2015 at 00:11:17 UTC, Walter Bright wrote:

 It does to me, and in common programming usage "list" is often 
 said instead of "linked list".


There seems to be a lot of languages that make lists indexable... 
And the definition of what a list is seems to vary quite a lot.

Languages with something called a list that is indexable...
Java

Python
Perl
Jul 08 2015
parent reply "Observer" <spurious.address yahoo.com> writes:
On Thursday, 9 July 2015 at 00:48:40 UTC, Tofu Ninja wrote:

 Languages with something called a list that is indexable...
 Java

 Python
 Perl


Tcl (lists are an absolutely fundamental part of this language)
Lisp
Haskell
Icon
Jul 08 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 July 2015 at 01:26:57 UTC, Observer wrote:

 On Thursday, 9 July 2015 at 00:48:40 UTC, Tofu Ninja wrote:

 Languages with something called a list that is indexable...
 Java

 Python
 Perl


 Tcl (lists are an absolutely fundamental part of this language)
 Lisp
 Haskell
 Icon


Several of which actually use linked list for list and probably 
shouldn't provide random access.
Jul 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2015 12:56 AM, deadalnix wrote:

 Several of which actually use linked list for list and probably shouldn't
 provide random access.


Yes. Consider:

     for (int i = 0; i < list.length; ++i)
           sum += list[i];

If indexing was allowed on a list, this would seem like perfectly reasonable
code.
Jul 09 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 9 July 2015 at 19:19:42 UTC, Walter Bright wrote:

 On 7/9/2015 12:56 AM, deadalnix wrote:

 Several of which actually use linked list for list and 
 probably shouldn't
 provide random access.


 Yes. Consider:

     for (int i = 0; i < list.length; ++i)
           sum += list[i];

 If indexing was allowed on a list, this would seem like 
 perfectly reasonable code.


In many languages that is perfectly reasonable because list does 
not equal linked list. Its almost as if a list is an abstract 
concept and does not mean any one definite data structure, hmmm 
who wuda thunk that...
Jul 09 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 9 July 2015 at 20:57:54 UTC, Tofu Ninja wrote:

 On Thursday, 9 July 2015 at 19:19:42 UTC, Walter Bright wrote:

 On 7/9/2015 12:56 AM, deadalnix wrote:

 Several of which actually use linked list for list and 
 probably shouldn't
 provide random access.


 Yes. Consider:

     for (int i = 0; i < list.length; ++i)
           sum += list[i];

 If indexing was allowed on a list, this would seem like 
 perfectly reasonable code.


 In many languages that is perfectly reasonable because list 
 does not equal linked list. Its almost as if a list is an 
 abstract concept and does not mean any one definite data 
 structure, hmmm who wuda thunk that...


It's definitely true that the term list does not denote a 
particular data structure in computer science, so I disagree with 
Walter's reticence to use the term list with AliasList, but it's 
also true that some languages and libraries have stupidly put 
indexing on a linked list, which is what deadalnix was 
complaining about.

- Jonathan M Davis
Jul 09 2015
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 9 July 2015 at 19:19:42 UTC, Walter Bright wrote:

 On 7/9/2015 12:56 AM, deadalnix wrote:

 Several of which actually use linked list for list and 
 probably shouldn't
 provide random access.


 Yes. Consider:

     for (int i = 0; i < list.length; ++i)
           sum += list[i];

 If indexing was allowed on a list, this would seem like 
 perfectly reasonable code.


Yes, which is why it's so ridiculous that the List interface in 
Java provides indexing via the at function. Both ArrayList and 
LinkedList implement it, which is reasonable in the case of 
ArrayList and stupid in the case of LinkedList.

- Jonathan M Davis
Jul 09 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 9 July 2015 at 00:11:17 UTC, Walter Bright wrote:

 Which is why I simply picked the name Arguments. The s suffix 
 means plural, and doesn't give any preconceived notion about 
 what kind of collection it is. It's a convention I've been 
 using in the dmd source for some time now, and have found it to 
 be natural and pleasing.


Instead, it gives the idea that they're used specifically for 
arguments, which they aren't. They get used for a variety of 
things. Also, the term Arguments is going to be really confusing 
- just like talking about std.container.Array gets confusing, 
because the term array is already used for other stuff, and it's 
never clear what folks are talking about unless they get 
specific. At least when you use the term TypeTuple, everyone 
knows what you mean, even if it's a sucky name. Going with 
something like Arguments or Parameters or Aliases is just going 
to breed confusion.

- Jonathan M Davis
Jul 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2015 7:22 PM, Jonathan M Davis wrote:

 On Thursday, 9 July 2015 at 00:11:17 UTC, Walter Bright wrote:

 Which is why I simply picked the name Arguments. The s suffix means plural,
 and doesn't give any preconceived notion about what kind of collection it is.
 It's a convention I've been using in the dmd source for some time now, and
 have found it to be natural and pleasing.


 Instead, it gives the idea that they're used specifically for arguments, which
 they aren't. They get used for a variety of things. Also, the term Arguments is
 going to be really confusing - just like talking about std.container.Array gets
 confusing, because the term array is already used for other stuff, and it's
 never clear what folks are talking about unless they get specific. At least
when
 you use the term TypeTuple, everyone knows what you mean, even if it's a sucky
 name. Going with something like Arguments or Parameters or Aliases is just
going
 to breed confusion.


What about the 's' suffix?
Jul 08 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 9 July 2015 at 02:58:32 UTC, Walter Bright wrote:

 On 7/8/2015 7:22 PM, Jonathan M Davis wrote:

 On Thursday, 9 July 2015 at 00:11:17 UTC, Walter Bright wrote:

 Which is why I simply picked the name Arguments. The s suffix 
 means plural,
 and doesn't give any preconceived notion about what kind of 
 collection it is.
 It's a convention I've been using in the dmd source for some 
 time now, and
 have found it to be natural and pleasing.


 Instead, it gives the idea that they're used specifically for 
 arguments, which
 they aren't. They get used for a variety of things. Also, the 
 term Arguments is
 going to be really confusing - just like talking about 
 std.container.Array gets
 confusing, because the term array is already used for other 
 stuff, and it's
 never clear what folks are talking about unless they get 
 specific. At least when
 you use the term TypeTuple, everyone knows what you mean, even 
 if it's a sucky
 name. Going with something like Arguments or Parameters or 
 Aliases is just going
 to breed confusion.


 What about the 's' suffix?


It might work in a situation where the main word is clearly 
unique, but when you're talking about something like Argument or 
Alias, adding an s on the end does not help at all. It's far too 
easy to confuse it with other concepts in the language that have 
the same name, whereas putting something like List on the end 
wouldn't have that problem - e.g. no one is going to confuse 
AliasList for anything else, but if we had Aliases, it would be 
really easy to think that someone was referring to aliases like 
this

alias foo = bar;

and misunderstand what they were talking about - especially in 
verbal conversations.

- Jonathan M Davis
Jul 08 2015
parent "Xiaoxi" <xiaoxi 163.com> writes:
On Thursday, 9 July 2015 at 03:31:41 UTC, Jonathan M Davis wrote:

 alias foo = bar;

 and misunderstand what they were talking about - especially in 
 verbal conversations.

 - Jonathan M Davis


Maybe with time, people will learn to use d:s module system 
verbally and say things like " meta pack" when referring to 
meta.Pack etc.
Jul 08 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 July 2015 at 02:58:32 UTC, Walter Bright wrote:

 What about the 's' suffix?


I use it for collection names quite a lot. Like:

Foo[] foos;

But I wouldn't go for

alias Foos = Foo[];

Additionally, we have this language concept that is autounpacking 
and so on and have no name. It needs a name.

This construct does not exists in most languages, so we need to 
come up with a name.
Jul 09 2015
parent "Ettienne Gilbert" <ettienne.gilbert gmail.com> writes:
On Thursday, 9 July 2015 at 08:03:06 UTC, deadalnix wrote:
[..]

 Additionally, we have this language concept that is 
 autounpacking and so on and have no name. It needs a name.


[..]

Unrolling    ?
Jul 09 2015
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 9 July 2015 at 00:11:17 UTC, Walter Bright wrote:

 Which is why I simply picked the name Arguments. The s suffix 
 means plural, and doesn't give any preconceived notion about 
 what kind of collection it is. It's a convention I've been 
 using in the dmd source for some time now, and have found it to 
 be natural and pleasing.


+1

--
Paolo
Jul 09 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/8/15 8:11 PM, Walter Bright wrote:


 Which is why I simply picked the name Arguments. The s suffix means
 plural, and doesn't give any preconceived notion about what kind of
 collection it is. It's a convention I've been using in the dmd source
 for some time now, and have found it to be natural and pleasing.


It's not always plural (e.g. Arguments!(int)). And being plural doesn't 
lend itself well to documentation. When you want to define some finite 
things, you usually wrap that into a construct (collection, set, group, 
sequence, list, etc). It's much more natural to talk about a list of 
arguments or a list of aliases, than it is to talk about arguments 
(which imply you mean all arguments, or arguments as a classification).

-Steve
Jul 09 2015
prev sibling parent Adam <Adam and.Eve> writes:
On Tuesday, 7 July 2015 at 22:22:02 UTC, Walter Bright wrote:

 On 7/7/2015 2:20 PM, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template
 arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would 
 somehow imply "linked
 list".


 I opposed it because lists are not indexable, and tuples are.


huh? A List is an ordered sequence. Both are indexable.

https://en.wikipedia.org/wiki/Enumeration

Wiki:

A list is any enumeration of a set of items. List or lists may 
also refer to:

and

Some sets can be enumerated by means of a natural ordering (such 
as 1, 2, 3, 4, ... for the set of positive integers), but in 
other cases it may be necessary to impose a (perhaps arbitrary) 
ordering.



Why you use that logic to choose a word is a kinda strange. A 
List doesn't imply much except what people want it to. You are 
choosing a single interpretation to not use it, when there are 
many.

A List is what someone creates with a pen and paper. It has an 
ordering(the first one and last one). A linked list or "unordered 
list" are just versions of a list.

A list is a list is a list!

Regardless, it's probably not the best term to use

TArgList or TArgSeq would be more descriptive.
Sep 20 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/15 5:20 PM, David Nadlinger wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names.
 Template arguments are indexable, so "sequence" doesn't quite apply.


 Apparently Walter was opposed to using List, as that would somehow imply
 "linked list".


And rightly so. It's just that "sequence" doesn't seem better. -- Andrei
Jul 07 2015
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/07/2015 11:16 PM, Andrei Alexandrescu wrote:

 Template arguments are indexable, so "sequence" doesn't quite apply.


https://en.wikipedia.org/wiki/Sequence#Indexing
Jul 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/15 5:24 PM, Timon Gehr wrote:

 On 07/07/2015 11:16 PM, Andrei Alexandrescu wrote:

 Template arguments are indexable, so "sequence" doesn't quite apply.


 https://en.wikipedia.org/wiki/Sequence#Indexing


Hmm, fair enough. Sequential as opposed to associative. 
https://en.wikipedia.org/wiki/Sequence_container_(C%2B%2B) also comes to 
mind.

Then, at least let's use the whole darn word. Doesn't seem like the 
short form is helping a lot here.


Andrei
Jul 07 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/15 7:29 PM, Andrei Alexandrescu wrote:

 On 7/7/15 5:24 PM, Timon Gehr wrote:

 On 07/07/2015 11:16 PM, Andrei Alexandrescu wrote:

 Template arguments are indexable, so "sequence" doesn't quite apply.


 https://en.wikipedia.org/wiki/Sequence#Indexing


 Hmm, fair enough. Sequential as opposed to associative.
 https://en.wikipedia.org/wiki/Sequence_container_(C%2B%2B) also comes to
 mind.

 Then, at least let's use the whole darn word. Doesn't seem like the
 short form is helping a lot here.


 Andrei


In fact thinking of it AliasArray seems most descriptive. -- Andrei
Jul 07 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 7 July 2015 at 23:30:05 UTC, Andrei Alexandrescu 
wrote:

 In fact thinking of it AliasArray seems most descriptive. -- 
 Andrei


I like this as well, but calling it an array might make people 
think you can assign to its elements.
Jul 07 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/15 7:32 PM, Tofu Ninja wrote:

 On Tuesday, 7 July 2015 at 23:30:05 UTC, Andrei Alexandrescu wrote:

 In fact thinking of it AliasArray seems most descriptive. -- Andrei


 I like this as well, but calling it an array might make people think you
 can assign to its elements.


Well it depends on the element type, e.g. you can't assign to slots of 
an array of immutable elements because you can't assign the individual 
types to start with. By extension you can't assign to elements of an 
array of aliases because you can't assign an alias to another to start 
wityh. -- Andrei
Jul 07 2015
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/08/2015 01:30 AM, Andrei Alexandrescu wrote:


 In fact thinking of it AliasArray seems most descriptive. -- Andrei


Not really.

https://en.wikipedia.org/wiki/Array_data_structure
https://en.wikipedia.org/wiki/Array_data_type

Neither is is fitting.



 Jul 07 2015



prev sibling  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 7 July 2015 at 23:30:05 UTC, Andrei Alexandrescu 
wrote:

 In fact thinking of it AliasArray seems most descriptive. --


I think that that would be a really bad move, since we already 
use the term array for three other completely unrelated items in 
the language, and it really isn't an array in any kind of classic 
sense. It's an indexable list of heterogenous items where that 
list is a compile-time construct and not a runtime data 
structure. There's really nothing else like it, and the term 
array arguably carries even more baggage with it than tuple, and 
tuple has always been a bad fit - both because it implies that 
you can nest them (whereas they self-flatten) and because we 
already have tuples with std.typecons.Tuple. We'd be going from 
having two tuple types and three array types to one tuple type 
and four array types. Much as I think that it's a mistake to use 
the term tuple for TypeTuple/AliasSeq/etc., I think that it would 
be far better to name it AliasTuple than AliasArray.

- Jonathan M Davis



 Jul 08 2015



prev sibling  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 08-Jul-2015 02:29, Andrei Alexandrescu wrote:

 On 7/7/15 5:24 PM, Timon Gehr wrote:

 On 07/07/2015 11:16 PM, Andrei Alexandrescu wrote:

 Template arguments are indexable, so "sequence" doesn't quite apply.


 https://en.wikipedia.org/wiki/Sequence#Indexing


 Hmm, fair enough. Sequential as opposed to associative.
 https://en.wikipedia.org/wiki/Sequence_container_(C%2B%2B) also comes to
 mind.

 Then, at least let's use the whole darn word. Doesn't seem like the
 short form is helping a lot here.


I believe Seq is quite fitting as the venerable TypeTuple  was used 
frequently enough to benefit from shorter form IMHO.

Scala's Seq[T] is a sequential container (pretty much anything 
array-like), so there is precedent.

-- 
Dmitry Olshansky



 Jul 08 2015



prev sibling next sibling parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


AliasSeq?? What is that even supposed to mean? Are we just 
throwing random words together?



 Jul 07 2015



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Tuesday, 7 July 2015 at 22:52:09 UTC, rsw0x wrote:

 AliasSeq?? What is that even supposed to mean? Are we just 
 throwing random words together?


A sequence of aliases, personally I think it is a much better 
name. But maybe seq could be replaced with something else, though 
I don't really mind seq. AliasList seems a little bit better.



 Jul 07 2015



  parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Tuesday, 7 July 2015 at 23:30:25 UTC, Tofu Ninja wrote:

 On Tuesday, 7 July 2015 at 22:52:09 UTC, rsw0x wrote:

 AliasSeq?? What is that even supposed to mean? Are we just 
 throwing random words together?


 A sequence of aliases, personally I think it is a much better 
 name. But maybe seq could be replaced with something else, 
 though I don't really mind seq. AliasList seems a little bit 
 better.


it's far closer to a tuple, list, or array than a sequence.



 Jul 07 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Wednesday, 8 July 2015 at 01:26:22 UTC, rsw0x wrote:

 A sequence of aliases, personally I think it is a much better 
 name. But maybe seq could be replaced with something else, 
 though I don't really mind seq. AliasList seems a little bit 
 better.


 it's far closer to a tuple, list, or array than a sequence.


Mmh, TypeTuple had 2 problems, it didn't solely consist of types, 
and the term tuple is overloaded by value tuples.
But indeed AliasTuple would be descriptive name IMHO.



 Jul 08 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 8 July 2015 at 08:53:52 UTC, Martin Nowak wrote:

 On Wednesday, 8 July 2015 at 01:26:22 UTC, rsw0x wrote:

 A sequence of aliases, personally I think it is a much better 
 name. But maybe seq could be replaced with something else, 
 though I don't really mind seq. AliasList seems a little bit 
 better.


 it's far closer to a tuple, list, or array than a sequence.


 Mmh, TypeTuple had 2 problems, it didn't solely consist of 
 types, and the term tuple is overloaded by value tuples.
 But indeed AliasTuple would be descriptive name IMHO.


Tuples are not expected to auto unpack either.



 Jul 08 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 8 July 2015 at 08:59:15 UTC, deadalnix wrote:

 On Wednesday, 8 July 2015 at 08:53:52 UTC, Martin Nowak wrote:

 On Wednesday, 8 July 2015 at 01:26:22 UTC, rsw0x wrote:

 A sequence of aliases, personally I think it is a much 
 better name. But maybe seq could be replaced with something 
 else, though I don't really mind seq. AliasList seems a 
 little bit better.


 it's far closer to a tuple, list, or array than a sequence.


 Mmh, TypeTuple had 2 problems, it didn't solely consist of 
 types, and the term tuple is overloaded by value tuples.
 But indeed AliasTuple would be descriptive name IMHO.


 Tuples are not expected to auto unpack either.


Yeah. Every name sucks. Alias seems to solve the first half of 
the name reasonably well, but nothing that anyone has come up 
with really solves the second half.

TypeTuples/AliasSeqs/Whatever really aren't tuples, because they 
don't nest, and they auto flatten (which pretty much no who has 
dealt with tuples before is going to expect from a tuple). So, 
tuples really gives the wrong impression, but it has the 
advantage of implying that it holds a heterogenous group of 
items, whereas pretty much anything else risks implying that it 
holds a homogeneous list of items.

Array (as Andrei has suggested) is already a very overloaded term 
in D, and it implies a runtime data structure, which this isn't. 
Certainly, when folks think of arrays, they're not going to think 
of anything like TypeTuple/AliasSeq.

List is by far the most generic, but it doesn't imply 
indexability, so Walter doesn't like - though Seq doesn't imply 
indexability either, so if that's his complaint, I don't see how 
it makes much differences whether we go with List or Seq. They 
seem pretty interchangeable to me.

Has anyone come up with anything other than Tuple, Array, List, 
or Seq? Simply throwing an "s" on the end like they did with 
Arguments? Then we have Aliases. I doubt that that's a good idea, 
but it would be an option.

As far as I can tell, _all_ of our options suck for one reason or 
another. If I had to pick, I'd pick List, simply because it's the 
most generic, and there won't be anyone complaining about what 
Seq might mean if they don't grok that it's Sequence, but it 
seems like no matter what we pick, there's going to be 
complaining.

- Jonathan M Davis



 Jul 08 2015



 next sibling parent reply "ixid" <adamsibson hotmail.com>  writes:


On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis wrote:

 Has anyone come up with anything other than Tuple, Array, List, 
 or Seq? Simply throwing an "s" on the end like they did with 
 Arguments? Then we have Aliases. I doubt that that's a good 
 idea, but it would be an option.


What's wrong with Aliases?



 Jul 08 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 8 July 2015 at 09:49:59 UTC, ixid wrote:

 On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis 
 wrote:

 Has anyone come up with anything other than Tuple, Array, 
 List, or Seq? Simply throwing an "s" on the end like they did 
 with Arguments? Then we have Aliases. I doubt that that's a 
 good idea, but it would be an option.


 What's wrong with Aliases?


Well, it says less about what it is than something like AliasList 
or AliasTuple would, but it also runs afoul of the same problem 
that std.container.Array does. It's using the same name as 
something else that's commonly talked about but means something 
quite different (even if it's related). When folks talk about 
aliases right now, they do _not_ mean Aliases. They're talking 
about stuff like

alias foo = bar;

And renaming TypeTuple to Aliases is just going to increase 
confusion.

- Jonathan M Davis



 Jul 08 2015



  parent reply "Xiaoxi" <xiaoxi 163.com>  writes:


On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis wrote:

 And renaming TypeTuple to Aliases is just going to increase 
 confusion.

 - Jonathan M Davis


It's basically just __VA_ARGS__ on steroids, thus 'Arguments' is 
good, there's precedence in C(Args).



 Jul 08 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:

 On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis 
 wrote:

 And renaming TypeTuple to Aliases is just going to increase 
 confusion.

 - Jonathan M Davis


 It's basically just __VA_ARGS__ on steroids, thus 'Arguments' 
 is good, there's precedence in C(Args).


LOL. Then what about when you use it for _parameters_ rather than 
arguments? Or when you use it areas that have _nothing_ to do 
with functions - e.g.

foreach(S; TypeTuple!(string, char[], wstring, dstring))
{
     //...
}

Naming it Arguments gives the impression that it's specifically 
related to arguments, and that's just one small area that it gets 
used in. And that's part of what's so hard about naming it. It 
just does way too many things to name easily.

- Jonathan M Davis



 Jul 08 2015



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 8 July 2015 at 16:44:13 UTC, Jonathan M Davis wrote:

 On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:

 On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis 
 wrote:

 And renaming TypeTuple to Aliases is just going to increase 
 confusion.

 - Jonathan M Davis


 It's basically just __VA_ARGS__ on steroids, thus 'Arguments' 
 is good, there's precedence in C(Args).


 LOL. Then what about when you use it for _parameters_ rather 
 than arguments? Or when you use it areas that have _nothing_ to 
 do with functions - e.g.

 foreach(S; TypeTuple!(string, char[], wstring, dstring))
 {
     //...
 }

 Naming it Arguments gives the impression that it's specifically 
 related to arguments, and that's just one small area that it 
 gets used in. And that's part of what's so hard about naming 
 it. It just does way too many things to name easily.

 - Jonathan M Davis


Not going to say if it is good or bad proposal, but your comment 
is not strictly relevant - template arguments are also arguments 
in D. It is exactly the term dlang.org grammar spec uses.



 Jul 08 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 8 July 2015 at 17:09:14 UTC, Dicebot wrote:

 On Wednesday, 8 July 2015 at 16:44:13 UTC, Jonathan M Davis 
 wrote:

 Naming it Arguments gives the impression that it's 
 specifically related to arguments, and that's just one small 
 area that it gets used in. And that's part of what's so hard 
 about naming it. It just does way too many things to name 
 easily.

 - Jonathan M Davis


 Not going to say if it is good or bad proposal, but your 
 comment is not strictly relevant - template arguments are also 
 arguments in D. It is exactly the term dlang.org grammar spec 
 uses.


Yes, but TypeTuple isn't just used for template arguments - or 
function arguments. In other circumstances, it's used for 
parameters or even for stuff that has nothing to do with either - 
e.g. in a foreach loop.

- Jonathan M Davis



 Jul 08 2015



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/08/2015 06:44 PM, Jonathan M Davis wrote:

 On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:

 On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis wrote:

 And renaming TypeTuple to Aliases is just going to increase confusion.

 - Jonathan M Davis


 It's basically just __VA_ARGS__ on steroids, thus 'Arguments' is good,
 there's precedence in C(Args).


 LOL. Then what about when you use it for _parameters_ rather than
 arguments? Or when you use it areas that have _nothing_ to do with
 functions - e.g.

 foreach(S; TypeTuple!(string, char[], wstring, dstring))
 {
      //...
 }

 Naming it Arguments gives the impression that it's specifically related
 to arguments, and that's just one small area that it gets used in. And
 that's part of what's so hard about naming it. It just does way too many
 things to name easily.

 - Jonathan M Davis


I assume the rationale is that the thing you get is literally the 
arguments to the template.

alias Asdf(T...)=T;

Asdf!(string,char[],wstring,dstring)
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Arguments

It's the identity function on template argument lists. This is needed 
because those do not have their own syntax.



 Jul 08 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 8 July 2015 at 17:15:50 UTC, Timon Gehr wrote:

 On 07/08/2015 06:44 PM, Jonathan M Davis wrote:

 On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:

 On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis 
 wrote:

 And renaming TypeTuple to Aliases is just going to increase 
 confusion.

 - Jonathan M Davis


 It's basically just __VA_ARGS__ on steroids, thus 'Arguments' 
 is good,
 there's precedence in C(Args).


 LOL. Then what about when you use it for _parameters_ rather 
 than
 arguments? Or when you use it areas that have _nothing_ to do 
 with
 functions - e.g.

 foreach(S; TypeTuple!(string, char[], wstring, dstring))
 {
      //...
 }

 Naming it Arguments gives the impression that it's 
 specifically related
 to arguments, and that's just one small area that it gets used 
 in. And
 that's part of what's so hard about naming it. It just does 
 way too many
 things to name easily.

 - Jonathan M Davis


 I assume the rationale is that the thing you get is literally 
 the arguments to the template.

 alias Asdf(T...)=T;

 Asdf!(string,char[],wstring,dstring)
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Arguments

 It's the identity function on template argument lists. This is 
 needed because those do not have their own syntax.


Sure, but they could also represent a template's parameters, not 
just the arguments. It all depends on what you're using the 
TypeTuple for.

- Jonathan M Davis



 Jul 08 2015



  parent  "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 8 July 2015 at 17:21:06 UTC, Jonathan M Davis wrote:

 Sure, but they could also represent a template's parameters, 
 not just the arguments. It all depends on what you're using the 
 TypeTuple for.


No matter what they represent, they ARE template arguments. That 
is a simple identity, as Timon has mentioned. Your reasoning is 
similar to saying that variables shouldn't be called variables 
because they can be immutable (not necessarily immutable in 
language terms but logically).

Trying to name argument lists by their usage pattern is doomed 
from the very beginning because they have many absolutely 
unrelated applications.



 Jul 08 2015



prev sibling  parent  "rmc" <rjmcguire gmail.com>  writes:


On Wednesday, 8 July 2015 at 16:44:13 UTC, Jonathan M Davis wrote:

 On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:

 On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis 
 wrote:

 And renaming TypeTuple to Aliases is just going to increase 
 confusion.

 - Jonathan M Davis


 It's basically just __VA_ARGS__ on steroids, thus 'Arguments' 
 is good, there's precedence in C(Args).


 LOL. Then what about when you use it for _parameters_ rather 
 than arguments? Or when you use it areas that have _nothing_ to 
 do with functions - e.g.

 foreach(S; TypeTuple!(string, char[], wstring, dstring))
 {
     //...
 }

 Naming it Arguments gives the impression that it's specifically 
 related to arguments, and that's just one small area that it 
 gets used in. And that's part of what's so hard about naming 
 it. It just does way too many things to name easily.

 - Jonathan M Davis


You just made the argument for calling it Arguments by arguing 
against its name being Arguments.

arguments and parameters are both basically the same thing and so 
is the example where you use it as the arguments to a foreach 
loop.

Most of the suggestions are too low level, fact is its a Tuple :D



 Jul 10 2015



prev sibling  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/8/15 5:49 AM, ixid wrote:

 On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis wrote:

 Has anyone come up with anything other than Tuple, Array, List, or
 Seq? Simply throwing an "s" on the end like they did with Arguments?
 Then we have Aliases. I doubt that that's a good idea, but it would be
 an option.


 What's wrong with Aliases?


It's plural. How to talk about Aliases? That was my main issue with 
Arguments.

"use a TypeTuple" -> "use an Aliases"

-Steve



 Jul 08 2015



  parent reply "ixid" <nuaccount gmail.com>  writes:


On Wednesday, 8 July 2015 at 17:53:05 UTC, Steven Schveighoffer 
wrote:

 It's plural. How to talk about Aliases? That was my main issue 
 with Arguments.

 "use a TypeTuple" -> "use an Aliases"

 -Steve


"use Aliases" or "use the Aliases".

I'm not arguing for Aliases but that seems like a non-problem. If 
something more general is required then Terms or something like 
that.



 Jul 08 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/8/15 2:22 PM, ixid wrote:

 On Wednesday, 8 July 2015 at 17:53:05 UTC, Steven Schveighoffer wrote:

 It's plural. How to talk about Aliases? That was my main issue with
 Arguments.

 "use a TypeTuple" -> "use an Aliases"

 -Steve


 "use Aliases" or "use the Aliases".

 I'm not arguing for Aliases but that seems like a non-problem. If
 something more general is required then Terms or something like that.


It still doesn't read correctly.

I'll give you an example from 
std.meta:https://github.com/D-Programming-Language/phobos/blob/master/std/meta.d#L146

"Returns a typetuple created from TList with the first occurrence, if 
any, of T removed."

Possible options:

"Returns Aliases created from TList with the first occurrence, if any, 
of T removed."

"Returns the Aliases created from TList with the first occurrence, if 
any, of T removed."

"Returns an instance of Aliases created from TList with the first 
occurrence, if any, of T removed."

I don't like them. However, use AliasSeq:

"Returns an AliasSeq created from TList with the first occurrence, if 
any, of T removed."

The difference is subtle, but definitely clearer and less awkward.

BTW, others have argued that typetuple above doesn't refer to the 
TypeTuple type, but the actual typetuple concept as described in the 
spec (a tuple of types). However, in this case, TList doesn't have to be 
strictly types, so this is not correct. So this should be changed.

The more I think about this, I think AliasTuple is probably the best 
answer. We have "type tuples" and "value tuples", "alias tuples" seems 
like a natural fit.

-Steve



 Jul 09 2015



 next sibling parent reply "ixid" <adamsibson hotmail.com>  writes:


On Thursday, 9 July 2015 at 11:34:56 UTC, Steven Schveighoffer 
wrote:

 The more I think about this, I think AliasTuple is probably the 
 best answer. We have "type tuples" and "value tuples", "alias 
 tuples" seems like a natural fit.

 -Steve


As we already have two tuples wouldn't a third be a bad idea for 
clarity or do you consider this meaning to overlap with the 
previous two?



 Jul 09 2015



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/9/15 7:41 AM, ixid wrote:

 On Thursday, 9 July 2015 at 11:34:56 UTC, Steven Schveighoffer wrote:

 The more I think about this, I think AliasTuple is probably the best
 answer. We have "type tuples" and "value tuples", "alias tuples" seems
 like a natural fit.


 As we already have two tuples wouldn't a third be a bad idea for clarity
 or do you consider this meaning to overlap with the previous two?


It is overlapping. A type tuple and an expression tuple are both 
sub-classifications of an alias tuple.

If we could start over, we should really just name this Tuple.

-Steve



 Jul 09 2015



prev sibling  parent  "Dominikus Dittes Scherkl"  writes:


On Thursday, 9 July 2015 at 11:34:56 UTC, Steven Schveighoffer 
wrote:

 "Returns Aliases created from TList with the first occurrence, 
 if any, of T removed."

 "Returns the Aliases created from TList with the first 
 occurrence, if any, of T removed."

 "Returns an instance of Aliases created from TList with the 
 first occurrence, if any, of T removed."

 I don't like them.


Hmm. I can't find anything misleading or arkward about them. 
Sounds pretty natural to me.



 Jul 09 2015



prev sibling  parent  "HaraldZealot" <harald_zealot tut.by>  writes:


On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis wrote:

 On Wednesday, 8 July 2015 at 08:59:15 UTC, deadalnix wrote:

 Yeah. Every name sucks. Alias seems to solve the first half of 
 the name reasonably well, but nothing that anyone has come up 
 with really solves the second half.

 [...]

 Array (as Andrei has suggested) is already a very overloaded 
 term in D, and it implies a runtime data structure, which this 
 isn't. Certainly, when folks think of arrays, they're not going 
 to think of anything like TypeTuple/AliasSeq.

 List is by far the most generic, but it doesn't imply 
 indexability, so Walter doesn't like - though Seq doesn't imply 
 indexability either, so if that's his complaint, I don't see 
 how it makes much differences whether we go with List or Seq. 
 They seem pretty interchangeable to me.

 [...]

 - Jonathan M Davis


Perhaps in such case we are going to invent new word? How about a 
kind of portmoneu word? For example tree + heap => treap. And we 
can have alias+list => aliast. No one have such word before an no 
impure association.



 Jul 08 2015



prev sibling next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


What basically happened is that I discussed that with pretty much 
everybody (including you at DConf) and really, nothing better 
came up.



 Jul 08 2015



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


I have just giggled.

Wonder if there will be any proposals in this thread that haven't 
already been mentioned in same thread. Though now it is much more 
funny because you keep it renaming right in master repeating all 
already considered and discarded points.

Sorry for being overly sarcastic, but I just can't take this 
seriously anymore :)



 Jul 08 2015



prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


I also saw this change and was horrified. It just replaced one 
bad named (Arguments) by another. I just didn't want to stir up 
further trouble. But now that it's on the table, here's my 
opinion:

For me, "sequence" always reminds me of the mathematical concept, 
where elements are of the same type (e.g. only real numbers, but 
not a mixture of scalars and vectors), and usually each element 
has some relation to either its predecessor, or its index. This 
doesn't fit with TypeTuples at all.

Likewise, an array (at least in D) always has exactly one element 
type. This doesn't apply to TypeTuples either.

The name I find most fitting to describe them is "tuple". The 
trouble with the former name is that it implies them being a 
tuple of types, although they don't need to be. So IMO we just 
need to find a better specifier.

(Personally I would be fine with "list", too, but Walter finds it 
misleading.)

I like "AliasTuple" as suggested by Martin, although it isn't a 
perfect fit either when you think of `alias` template params, 
which don't match `int`, while `int` can be an element of a 
TypeTuple. Alternatively "ArgumentsTuple", or 
"TemplateArgumentsTuple", but the latter is too long.



 Jul 08 2015



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/08/2015 11:38 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm gmx.net>" wrote:

 I like "AliasTuple" as suggested by Martin, although it isn't a perfect
 fit either when you think of `alias` template params, which don't match
 `int`, while `int` can be an element of a TypeTuple.


But this works: alias Int = int;

The right fix for this issue is to fix the language. This does not make 
any sense.



 Jul 08 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/8/15 1:44 PM, Timon Gehr wrote:

 On 07/08/2015 11:38 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
 <schuetzm gmx.net>" wrote:

 I like "AliasTuple" as suggested by Martin, although it isn't a perfect
 fit either when you think of `alias` template params, which don't match
 `int`, while `int` can be an element of a TypeTuple.


 But this works: alias Int = int;

 The right fix for this issue is to fix the language. This does not make
 any sense.


Yes, Walter at dconf also (I think) agreed this at least needs to be fixed:

alias Int = int;

template T(alias X) { enum a = 1;}

int x = T!Int.a; // error

In addition, this doesn't work:

alias foo = 2;

But this does:

int x = T!2.a;

I think alias should be the same anywhere you use it. And Alias<insert 
term here> for a name for what TypeTuple/Arguments/AliasSeq is, seems 
like an appropriate name given how template aliases work. Not my 
favorite, but it's at least based in logic.

-Steve



 Jul 08 2015



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer 
wrote:

 On 7/8/15 1:44 PM, Timon Gehr wrote:

 On 07/08/2015 11:38 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
 <schuetzm gmx.net>" wrote:

 I like "AliasTuple" as suggested by Martin, although it isn't 
 a perfect
 fit either when you think of `alias` template params, which 
 don't match
 `int`, while `int` can be an element of a TypeTuple.


 But this works: alias Int = int;

 The right fix for this issue is to fix the language. This does 
 not make
 any sense.


 Yes, Walter at dconf also (I think) agreed this at least needs 
 to be fixed:

 alias Int = int;

 template T(alias X) { enum a = 1;}

 int x = T!Int.a; // error

 In addition, this doesn't work:

 alias foo = 2;

 But this does:

 int x = T!2.a;

 I think alias should be the same anywhere you use it. And 
 Alias<insert term here> for a name for what 
 TypeTuple/Arguments/AliasSeq is, seems like an appropriate name 
 given how template aliases work. Not my favorite, but it's at 
 least based in logic.

 -Steve


Yes, yes, yes, 20 times yes. There are some quirks with what can 
be aliased depending on how the alias is declared, this needs to 
be unified.

The thing we are naming here is some collection of aliases. 
Talking to everybody, the 2 names that came up frequently for 
this collection are List and Sequence. I personally don't mind, 
but Walter had strong views against List, so I went for Sequence.

Now we should decide for a term for this entity we have in D that 
is kind of tuple but auto unpack. This construct does not exists 
in other languages, so, as explained by Jonathan, no existing 
name will fit 100% . I'd say we pick some name that evoke an 
ordered collection and that which is not already used for some 
existing construct in D (which rules out array for instance) or 
have a well defined meaning (like tuple).

Sequence fit the bill. I don't mind using another name that fit 
the bill as well. Nobody came up with that name yet.



 Jul 08 2015



  parent reply "Observer" <spurious.address yahoo.com>  writes:


On Wednesday, 8 July 2015 at 20:11:16 UTC, deadalnix wrote:

 Sequence fit the bill. I don't mind using another name that fit 
 the bill as well. Nobody came up with that name yet.


I find that naming objects is a key part of programming, and to 
that end I own one copy of Roget's International Thesaurus 
(Crowell, 4th edition -- a quality thesaurus, not a cheap junk 
book) at work, and another copy that I keep at home.  It's the 
best reference I know of to jog your thinking out of a rut when 
you need some synonym that is just beyond your mental reach.

Looking up the concept in this case yields words like "series", 
"chain", and "train".  There are lots more choices, but those are 
some of the simple, short ones.  So we could have AliasSeries or 
SerialAliases, AliasChain, etc.  I'm not saying I'm in favor of 
any of these in particular, or that I'm at all familiar with the 
underlying idea we're trying to name here; all I'm proposing is a 
process for generating alternative names.



 Jul 08 2015



 next sibling parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Wednesday, 8 July 2015 at 22:01:48 UTC, Observer wrote:

 I find that naming objects is a key part of programming, and to 
 that end I own one copy of Roget's International Thesaurus 
 (Crowell, 4th edition -- a quality thesaurus, not a cheap junk 
 book) at work, and another copy that I keep at home.  It's the 
 best reference I know of to jog your thinking out of a rut when 
 you need some synonym that is just beyond your mental reach.


Thats actually a pretty neat idea, I feel like I am going to 
start doing this when I have trouble naming things.



 Jul 08 2015



prev sibling  parent reply "Wyatt" <wyatt.epp gmail.com>  writes:


On Wednesday, 8 July 2015 at 22:01:48 UTC, Observer wrote:

 all I'm proposing is a process for generating alternative names.


AliasBall, AliasPile, AliasGroup, AliasSet, AliasLine...

(That is, I generally agree inventing a new term that fits isn't 
a bad idea.)

-Wyatt



 Jul 09 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 9 July 2015 at 13:47:58 UTC, Wyatt wrote:

 On Wednesday, 8 July 2015 at 22:01:48 UTC, Observer wrote:

 all I'm proposing is a process for generating alternative 
 names.


 AliasBall, AliasPile, AliasGroup, AliasSet, AliasLine...

 (That is, I generally agree inventing a new term that fits 
 isn't a bad idea.)

 -Wyatt


Sequence is not commonly used in D so far and many used it in the 
past (most commonly used where List and Sequence). These term are 
fine, for the most part, but none of them is any better than 
sequence.



 Jul 09 2015



prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer 
wrote:

 In addition, this doesn't work:

 alias foo = 2;


I think you are right that that should be allowed, but just out 
of curiosity, if that was allowed, then what would the purpose of 
enum be?



 Jul 08 2015



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 8 July 2015 at 20:14:55 UTC, Tofu Ninja wrote:

 On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer 
 wrote:

 In addition, this doesn't work:

 alias foo = 2;


 I think you are right that that should be allowed, but just out 
 of curiosity, if that was allowed, then what would the purpose 
 of enum be?


enum has all kind of bizare rules for arrays for instance. I'm 
not sure how justified it is to begin with, but that it is in and 
everybody uses them enum has its place is there to stay.



 Jul 08 2015



prev sibling  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/8/15 4:14 PM, Tofu Ninja wrote:

 On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer wrote:

 In addition, this doesn't work:

 alias foo = 2;


 I think you are right that that should be allowed, but just out of
 curiosity, if that was allowed, then what would the purpose of enum be?


Alias literally means "another name for". enum, used in this context, 
means "manifest constant value of". Both descriptions can be applied to 
2 (or any other literal) and reduce to the same effect, but when you 
start getting into non-literals, the meaning doesn't match:

int foo();

alias x = foo; // using x means to call foo
enum x = foo; // x is an enum int assigned the value of foo() evaluated 
at compile time

-Steve



 Jul 09 2015



prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer 
wrote:

 On 7/8/15 1:44 PM, Timon Gehr wrote:

 On 07/08/2015 11:38 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
 <schuetzm gmx.net>" wrote:

 I like "AliasTuple" as suggested by Martin, although it isn't 
 a perfect
 fit either when you think of `alias` template params, which 
 don't match
 `int`, while `int` can be an element of a TypeTuple.


 But this works: alias Int = int;

 The right fix for this issue is to fix the language. This does 
 not make
 any sense.




Of course, but I thought that was out of question. However...


 Yes, Walter at dconf also (I think) agreed this at least needs 
 to be fixed:


... that's nice to hear!

Then I think we should definitely go with "AliasTuple".



 Jul 09 2015



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/9/15 4:54 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:

 On Wednesday, 8 July 2015 at 18:01:36 UTC, Steven Schveighoffer wrote:

 On 7/8/15 1:44 PM, Timon Gehr wrote:

 On 07/08/2015 11:38 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
 <schuetzm gmx.net>" wrote:

 I like "AliasTuple" as suggested by Martin, although it isn't a perfect
 fit either when you think of `alias` template params, which don't match
 `int`, while `int` can be an element of a TypeTuple.


 But this works: alias Int = int;

 The right fix for this issue is to fix the language. This does not make
 any sense.




 Of course, but I thought that was out of question. However...


 Yes, Walter at dconf also (I think) agreed this at least needs to be
 fixed:


 .... that's nice to hear!


After the last talk (I think) David Nadlinger went around with a 
hand-written piece of code that did something similar to what I wrote 
and asked everyone whether it should compile or not. Both Walter and I 
said it should (I thought alias works as long as you are passing a 
*symbol* and not a keyword, and Int is a symbol). But it doesn't because 
T!(Int) and T!(int) are considered the same template instantiation.

Only I think 2 people correctly realized it was currently invalid. 
Taking a look through phobos, you will see all kinds of duplicate 
templates, one that is SomeTemplate(alias T) and one that is 
SomeTemplate(T) (which do the same thing), just for this limitation. I 
think it's a huge waste of code space and mental confusion.


 Then I think we should definitely go with "AliasTuple".


Yeah, I have been thinking AliasTuple is likely the best name. It goes 
right along with "type tuple" and "expression tuple". If we were 
designing from scratch, I'd say this thing is called Tuple, and 
std.typecons.Tuple would be ExpressionTuple.

-Steve



 Jul 09 2015



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/08/2015 08:01 PM, Steven Schveighoffer wrote:

 Yes, Walter at dconf also (I think) agreed this at least needs to be fixed:

 alias Int = int;

 template T(alias X) { enum a = 1;}

 int x = T!Int.a; // error


There should be no difference between Int and int after the alias 
declaration. The "symbol" vs. "non-symbol" distinction is arbitrary and 
does not buy anything.



 Jul 09 2015



prev sibling next sibling parent  "Sebastiaan Koppe" <mail skoppe.eu>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


Why not just iterate over every possible candidate and vote? 
Anyway, here is my unordered `list`:

Aliases,
AliasSet,
AliasList,
AliasEnum,
AliasRange,
AliasGroup,
AliasIndex,

Aliases has my vote.



 Jul 08 2015



prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


I reckon Collect would be a good name. It describes what you're 
doing: collecting some things together. Is also fits nicely with 
the currently private but hugely useful std.typetuple.Pack.


Collect: collect things together to one symbol, but they're not 
bound together, they'll auto-expand if they can.

Pack: pack things together, they only come apart explicitly (via 
.expand).


The best thing about it? It doesn't say anything misleading about 
the contents. It also doesn't say anything confusing about 
runtime vs compile-time.

Speaking as someone who's written ridiculous numbers of lines of 
code using TypeTuple and various incarnations of Pack, Collect 
fits my way of thinking.



 Jul 08 2015



  parent  "Meta" <jared771 gmail.com>  writes:


On Wednesday, 8 July 2015 at 16:29:25 UTC, John Colvin wrote:

 I reckon Collect would be a good name. It describes what you're 
 doing: collecting some things together. Is also fits nicely 
 with the currently private but hugely useful std.typetuple.Pack.


 Collect: collect things together to one symbol, but they're not 
 bound together, they'll auto-expand if they can.

 Pack: pack things together, they only come apart explicitly 
 (via .expand).


 The best thing about it? It doesn't say anything misleading 
 about the contents. It also doesn't say anything confusing 
 about runtime vs compile-time.

 Speaking as someone who's written ridiculous numbers of lines 
 of code using TypeTuple and various incarnations of Pack, 
 Collect fits my way of thinking.


Let's choose a name the cool kids will like and name it OmniSplat.



 Jul 08 2015



prev sibling next sibling parent reply "Zoadian" <no no.no>  writes:


It is a compiletime tuple so i'd vote for:
CtTuple



 Jul 09 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 9 July 2015 at 14:29:55 UTC, Zoadian wrote:

 It is a compiletime tuple so i'd vote for:
 CtTuple


Too bad it is not a tuple and it is not exclusively compile time. 
Otherwise, that'd be a great name.



 Jul 09 2015



 next sibling parent  "Xiaoxi" <xiaoxi 163.com>  writes:


On Thursday, 9 July 2015 at 15:03:25 UTC, deadalnix wrote:

 On Thursday, 9 July 2015 at 14:29:55 UTC, Zoadian wrote:

 It is a compiletime tuple so i'd vote for:
 CtTuple


 Too bad it is not a tuple and it is not exclusively compile 
 time. Otherwise, that'd be a great name.


Really? Proof to the contrary: it cant be indexed without first 
being copied into a runtime construct, its as much compiletime 
only as UDAs are.

alias Tuple(Args...) = Args;
int main(string args[])
{
   return Tuple!(1,2)[args.length];
}



 Jul 09 2015



prev sibling  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Thursday, 9 July 2015 at 15:03:25 UTC, deadalnix wrote:

 On Thursday, 9 July 2015 at 14:29:55 UTC, Zoadian wrote:

 It is a compiletime tuple so i'd vote for:
 CtTuple


 Too bad it is not a tuple [...]


Quoting from https://en.wikipedia.org/wiki/Tuple :


 A tuple is a finite ordered list of elements.


- finite: check
- ordered: check
- list of elements: check

Fits perfectly.

Interestingly, it goes on by saying:


 An n-tuple is defined inductively using the construction
 of an ordered pair.


Although not stated explicitly, this implies (a kind of) auto 
expanding!
=> Fits more than perfectly :-P



 Jul 09 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 9 July 2015 at 18:45:56 UTC, Marc Schütz wrote:

 Interestingly, it goes on by saying:


 An n-tuple is defined inductively using the construction
 of an ordered pair.


 Although not stated explicitly, this implies (a kind of) auto 
 expanding!
 => Fits more than perfectly :-P


No one who has ever seriously used tuples in any programming 
language I've ever heard of would expect tuples to auto expand. 
Auto expansion makes them _considerably_ less useful. In the case 
of TypeTuple/AliasSeq, the situation is a bit different, because 
we're not really talking about tuples here. Real tuples nest, and 
they don't auto expand. TypeTuple/AliasSeq is the _only_ case 
I've ever seen where someone tried to claim that something was a 
tuple when it didn't nest, or it auto-expanded. Folks have been 
consistently confused about the differences between TypeTuple and 
std.typecons.Tuple and the fact that TypeTuples auto expand. No 
one expects it - because tuples just don't do that in any actual 
programming languages. I question the validity of your 
interpretation of the theory as well, but even if it's valid, it 
doesn't match what's done in actual programming languages.

- Jonathan M Davis



 Jul 09 2015



 next sibling parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Jul 09, 2015 at 07:10:38PM +0000, Jonathan M Davis via Digitalmars-d
wrote:

prev sibling next sibling parent reply "Brian Rogoff" <brogoff gmail.com>  writes:


On Thursday, 9 July 2015 at 19:10:39 UTC, Jonathan M Davis wrote:

 On Thursday, 9 July 2015 at 18:45:56 UTC, Marc Schütz wrote:

 Interestingly, it goes on by saying:


 An n-tuple is defined inductively using the construction
 of an ordered pair.


 Although not stated explicitly, this implies (a kind of) auto 
 expanding!
 => Fits more than perfectly :-P


 No one who has ever seriously used tuples in any programming 
 language I've ever heard of would expect tuples to auto expand.


You're right. And after all of the discussion, I like the name 
AliasSeq more.
The fact that it sometimes elicits a 'WTF' reaction is perfect; 
it's a D thing (or a 'not normally exposed to the programmer 
thing') so you need to look up what it does. Using Tuple, List, 
or Array in the name is unhelpful, as those names are used a lot 
already.



 Jul 09 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 9 July 2015 at 19:45:21 UTC, Brian Rogoff wrote:

 And after all of the discussion, I like the name AliasSeq more.
 The fact that it sometimes elicits a 'WTF' reaction is perfect; 
 it's a D thing (or a 'not normally exposed to the programmer 
 thing') so you need to look up what it does. Using Tuple, List, 
 or Array in the name is unhelpful, as those names are used a 
 lot already.


Yeah. Arguably going with a weirder name has the advantage of 
making it so that you're less likely to assume that you 
understand it when you see it (since if you haven't studied up on 
it, you _don't_ understand it), whereas the other terms - 
especially Tuple - tend to make folks assume that they understand 
it when they really don't. No one understands 
TypeTuples/AliasSeqs without studying up on them. They're just 
too unique.

- Jonathan M Davis



 Jul 09 2015



prev sibling  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Thursday, 9 July 2015 at 19:10:39 UTC, Jonathan M Davis wrote:

 On Thursday, 9 July 2015 at 18:45:56 UTC, Marc Schütz wrote:

 Interestingly, it goes on by saying:


 An n-tuple is defined inductively using the construction
 of an ordered pair.


 Although not stated explicitly, this implies (a kind of) auto 
 expanding!
 => Fits more than perfectly :-P


 No one who has ever seriously used tuples in any programming 
 language I've ever heard of would expect tuples to auto expand. 
 Auto expansion makes them _considerably_ less useful. In the 
 case of TypeTuple/AliasSeq, the situation is a bit different, 
 because we're not really talking about tuples here. Real tuples 
 nest, and they don't auto expand.


But my quote above that they _don't_ nest and _do_ auto-expand, 
how else could you construct n-tuples from pairs?


 TypeTuple/AliasSeq is the _only_ case I've ever seen where 
 someone tried to claim that something was a tuple when it 
 didn't nest, or it auto-expanded. Folks have been consistently 
 confused about the differences between TypeTuple and 
 std.typecons.Tuple and the fact that TypeTuples auto expand. No 
 one expects it - because tuples just don't do that in any 
 actual programming languages. I question the validity of your 
 interpretation of the theory as well, but even if it's valid, 
 it doesn't match what's done in actual programming languages.


I personally think this auto-expanding argument is overrated. I 
don't have any particular expectation regarding auto-expansion 
towards the concept "tuple". Sure, it may be surprising, but that 
doesn't stop an auto expanding tuple from being a tuple, just 
like Perl arrays being auto-expanding doesn't stop them from 
being arrays.



 Jul 10 2015



 next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote:

 I personally think this auto-expanding argument is overrated. I 
 don't have any particular expectation regarding auto-expansion 
 towards the concept "tuple".


But he's right that we have auto-expanding and non-expanding 
tuples, so having a different term for the auto-expanding one 
would help a bit.



 Jul 10 2015



 next sibling parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote:

 I personally think this auto-expanding argument is overrated. 
 I don't have any particular expectation regarding 
 auto-expansion towards the concept "tuple".


 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


Only minimally. We also have different kinds of ranges, but their 
names are all just "XxxRange". I can of course only speak for 
myself, but having a `Tuple` and an `AliasTuple`, one 
auto-expanding and the other not, doesn't confuse me.



 Jul 10 2015



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


This unpacking is called splatting in some other PLs that have a 
splat operator. Maybe we can use that to describe the 
unpackedness, e.g. AliasSplat.



 Jul 10 2015



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 10 July 2015 at 09:05:10 UTC, Martin Nowak wrote:

 On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


 This unpacking is called splatting in some other PLs that have 
 a splat operator. Maybe we can use that to describe the 
 unpackedness, e.g. AliasSplat.


http://www.infoq.com/presentations/functional-pros-cons



 Jul 10 2015



prev sibling next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 10 July 2015 at 09:05:10 UTC, Martin Nowak wrote:

 On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


 This unpacking is called splatting in some other PLs that have 
 a splat operator. Maybe we can use that to describe the 
 unpackedness, e.g. AliasSplat.


http://www.infoq.com/presentations/functional-pros-cons



 Jul 13 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 10 July 2015 at 09:05:10 UTC, Martin Nowak wrote:

 On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


 This unpacking is called splatting in some other PLs that have 
 a splat operator. Maybe we can use that to describe the 
 unpackedness, e.g. AliasSplat.


You know what, I in fact start to like splat. This convey exactly 
what this is and is already used in the same way in other area of 
programming.



 Jul 13 2015



  parent  "ixid" <adamsibson hotmail.com>  writes:


On Monday, 13 July 2015 at 14:24:23 UTC, deadalnix wrote:

 On Friday, 10 July 2015 at 09:05:10 UTC, Martin Nowak wrote:

 On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote:

 But he's right that we have auto-expanding and non-expanding 
 tuples, so having a different term for the auto-expanding one 
 would help a bit.


 This unpacking is called splatting in some other PLs that have 
 a splat operator. Maybe we can use that to describe the 
 unpackedness, e.g. AliasSplat.


 You know what, I in fact start to like splat. This convey 
 exactly what this is and is already used in the same way in 
 other area of programming.


Is the inverse a squidge?



 Jul 13 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote:

 I personally think this auto-expanding argument is overrated. I 
 don't have any particular expectation regarding auto-expansion 
 towards the concept "tuple". Sure, it may be surprising, but 
 that doesn't stop an auto expanding tuple from being a tuple, 
 just like Perl arrays being auto-expanding doesn't stop them 
 from being arrays.


You know there a thing scientific do that is called experiment. 
In this case the experiment of calling this a tuple has been 
made, and it confused the hell out of everybody for years.

You can argue against reality all you want. The fact is, people 
expect tuples to not autoexpand.



 Jul 10 2015



  parent  "rsw0x" <anonymous anonymous.com>  writes:


On Friday, 10 July 2015 at 10:05:19 UTC, deadalnix wrote:

 On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote:

 I personally think this auto-expanding argument is overrated. 
 I don't have any particular expectation regarding 
 auto-expansion towards the concept "tuple". Sure, it may be 
 surprising, but that doesn't stop an auto expanding tuple from 
 being a tuple, just like Perl arrays being auto-expanding 
 doesn't stop them from being arrays.


 You know there a thing scientific do that is called experiment. 
 In this case the experiment of calling this a tuple has been 
 made, and it confused the hell out of everybody for years.

 You can argue against reality all you want. The fact is, people 
 expect tuples to not autoexpand.


the reason tuple was confusing is because it's already used by 
another completely distinct type.



 Jul 10 2015



prev sibling next sibling parent  Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 7/7/15, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 So I thought we were supposed to replace bad names with good names.
 Template arguments are indexable, so "sequence" doesn't quite apply.

 What happened? Why are we replacing a crappy term with another crappy term?


 Andrei


As far as I can tell there's a giant elephant in the room and his name
is `Tuple`.

The problem is there's a Tuple template in Phobos. If you rename that
you get a solid new name for a language tuple.

/mytwocents



 Jul 09 2015



prev sibling next sibling parent  "Nicholas Wilson" <iamthewilsonator hotmail.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


Well, if
     alias Identity(T) = T;
then
     alias Identities(T...) = T;

or just make
      alias Identity(T...) = T;



 Jul 13 2015



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


Splat ? Would that work ?



 Jul 13 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


 Splat ? Would that work ?


Um. Seriously? I don't see how that would result in anything but 
ridicule. What's D do? It goes splat.

- Jonathan M Davis



 Jul 13 2015



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 13 July 2015 at 22:11:39 UTC, Jonathan M Davis wrote:

 On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" 
 doesn't quite apply.

 What happened? Why are we replacing a crappy term with 
 another crappy term?


 Andrei


 Splat ? Would that work ?


 Um. Seriously? I don't see how that would result in anything 
 but ridicule. What's D do? It goes splat.

 - Jonathan M Davis


Yes seriously. I had the same reaction at first, but it seems 
that this is exactly the word we are looking for.



 Jul 14 2015



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-07-14 00:11, Jonathan M Davis wrote:


 Um. Seriously? I don't see how that would result in anything but
 ridicule. What's D do? It goes splat.


Variadic arguments are sometimes called "splat" in some languages, like 
Ruby. Or it's rather the operator, "*", that's called the splat operator.

-- 
/Jacob Carlborg



 Jul 14 2015



  parent  "Meta" <jared771 gmail.com>  writes:


On Tuesday, 14 July 2015 at 11:14:58 UTC, Jacob Carlborg wrote:

 On 2015-07-14 00:11, Jonathan M Davis wrote:


 Um. Seriously? I don't see how that would result in anything 
 but
 ridicule. What's D do? It goes splat.


 Variadic arguments are sometimes called "splat" in some 
 languages, like Ruby. Or it's rather the operator, "*", that's 
 called the splat operator.


I think this is what we want. Varargs in Ruby auto-expand, so 
they behave in a very similar manner to D's template parameters. 
AliasSplat or TemplateSplat both seem like good options.



 Jul 14 2015



prev sibling next sibling parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


 Splat ? Would that work ?


Do you really think Splat is better than the other suggestions in 
this thread. I really don't want to have to start writing Splat 
all over my code, just feels dirty...



 Jul 13 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:


 Splat ? Would that work ?


No.  Just make it AliasList and call it a day.  "List" does not 
mean unindexable linked list except in the minds of a few.



 Jul 13 2015



  parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 14-Jul-2015 01:55, Mike wrote:

 On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:


 Splat ? Would that work ?


 No.  Just make it AliasList and call it a day.  "List" does not mean
 unindexable linked list except in the minds of a few.


Popular != the right thing.
List in CS at large is generally speaking not indexable nor defines such 
operations. So there may be a lot of people who don't care for what a 
list is, but that doesn't make list a synonym for sequence.

-- 
Dmitry Olshansky



 Jul 13 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:

 Popular != the right thing.
 List in CS at large is generally speaking not indexable nor 
 defines such operations. So there may be a lot of people who 
 don't care for what a list is, but that doesn't make list a 
 synonym for sequence.


Who decreed lists can not be indexable, seriously this seems 
really odd to me.



 Jul 13 2015



 next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 14-Jul-2015 02:38, Tofu Ninja wrote:

 On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:

 Popular != the right thing.
 List in CS at large is generally speaking not indexable nor defines
 such operations. So there may be a lot of people who don't care for
 what a list is, but that doesn't make list a synonym for sequence.


 Who decreed lists can not be indexable, seriously this seems really odd
 to me.


Come on...

https://en.wikipedia.org/wiki/List_%28abstract_data_type%29

Implementation of the list data structure may provide some of the 
following operations:

     a constructor for creating an empty list;
     an operation for testing whether or not a list is empty;
     an operation for prepending an entity to a list
     an operation for appending an entity to a list
     an operation for determining the first component (or the "head") of 
a list
     an operation for referring to the list consisting of all the 
components of a list except for its first (this is called the "tail" of 
the list.)

That's all. No indexing folks.

-- 
Dmitry Olshansky



 Jul 13 2015



 next sibling parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 13 July 2015 at 23:46:01 UTC, Dmitry Olshansky wrote:

 ... That's all. No indexing folks.


I suppose if wikipedia is going to be our guide, then array is 
the best choice.

 From the article:

 Some languages may allow list types to be indexed or sliced 
 like array types, in which case the data type is more 
 accurately described as an array.





 Jul 13 2015



prev sibling  parent reply "Mike" <none none.com>  writes:


On Monday, 13 July 2015 at 23:46:01 UTC, Dmitry Olshansky wrote:


 That's all. No indexing folks.


 From that very article:

"Some languages may allow list types to be indexed or sliced like 
array types"



 Jul 13 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/13/15 8:12 PM, Mike wrote:

 On Monday, 13 July 2015 at 23:46:01 UTC, Dmitry Olshansky wrote:


 That's all. No indexing folks.


  From that very article:

 "Some languages may allow list types to be indexed or sliced like array
 types"


Yah, I think arguments based on the preciseness of definitions are 
difficult to carry. It's a fact of life that terms like "list", 
"sequence", "slice" and even "array" do carry ambiguity. -- Andrei



 Jul 14 2015



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/13/15 7:38 PM, Tofu Ninja wrote:

 On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:

 Popular != the right thing.
 List in CS at large is generally speaking not indexable nor defines
 such operations. So there may be a lot of people who don't care for
 what a list is, but that doesn't make list a synonym for sequence.


 Who decreed lists can not be indexable, seriously this seems really odd
 to me.


It's just a matter of language ethos. Perl calls all arrays "lists", and 
if a new array-like feature comes about it that language, it would make 
sense to continue using that terminology. In D indexable and sliceable 
arrays are called "arrays" or "slices". That's a given. So adding 
something that is indexable and sliceable but is called a "list" is 
surprising. -- Andrei



 Jul 14 2015



prev sibling  parent reply "Mike" <none none.com>  writes:


On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:


 List in CS at large is generally speaking not indexable nor 
 defines such operations. So there may be a lot of people who 
 don't care for what a list is, but that doesn't make list a 
 synonym for sequence.


"Sequence" implies that Item(n+1) is in some way dependent on 
Item(n), so "Sequence" is a misnomer in this situation, and "Seq" 
is a misnomer for the misnomer.  Furthermore, given that in a 
linked-list, one must first obtain Item(n) to get to Item(n+1), 
"linked-list" is ironically a misnomer for what is truly a 
sequence.  Hence the reason for the need to persistently qualify 
it with the "linked-" prefix.

Even in the CS domain, the term "list" is rather general, as 
evident in its liberal usage in other programming languages and 
literature, and the need to persistently add 
qualifiers/quantifiers (e.g. "linked-") to disambiguate it.

"List" is agnostic to order, indexing, linking, or any other 
specific qualification/quantification.  It is simply an 
enumeration of items (e.g. "grocery list", "todo list", "laundry 
list").  "List" describes, quite well, the subject under 
scrutiny, evident by the fact that "AliasList" was one of the 
first terms to come to mind.



 Jul 13 2015



 next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/14/2015 02:10 AM, Mike wrote:

 On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:


 List in CS at large is generally speaking not indexable nor defines
 such operations. So there may be a lot of people who don't care for
 what a list is, but that doesn't make list a synonym for sequence.


 "Sequence" implies that Item(n+1) is in some way dependent on Item(n)


No, it does not.



 Jul 13 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/13/15 8:10 PM, Mike wrote:

 On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:


 List in CS at large is generally speaking not indexable nor defines
 such operations. So there may be a lot of people who don't care for
 what a list is, but that doesn't make list a synonym for sequence.


 "Sequence" implies that Item(n+1) is in some way dependent on Item(n),
 so "Sequence" is a misnomer in this situation, and "Seq" is a misnomer
 for the misnomer.


STL's "sequential containers" do not have serial dependence on items. 
There, "sequential" is meant as a converse of "associative".


 Furthermore, given that in a linked-list, one must
 first obtain Item(n) to get to Item(n+1), "linked-list" is ironically a
 misnomer for what is truly a sequence.  Hence the reason for the need to
 persistently qualify it with the "linked-" prefix.

 Even in the CS domain, the term "list" is rather general, as evident in
 its liberal usage in other programming languages and literature, and the
 need to persistently add qualifiers/quantifiers (e.g. "linked-") to
 disambiguate it.
 "List" is agnostic to order, indexing, linking, or any other specific
 qualification/quantification.  It is simply an enumeration of items
 (e.g. "grocery list", "todo list", "laundry list").  "List" describes,
 quite well, the subject under scrutiny, evident by the fact that
 "AliasList" was one of the first terms to come to mind.


I kinda agree in abstract especially because languages like Java and 
Perl use "lists" for arrays (see e.g. Java's ArrayList). Yet lists are 
often implicitly considered linked lists, ever since LISP. Also as I 
mentioned, each language bends terminology a bit one way or another. I 
don't think "list" is appropriate for describing a D abstraction that is 
indexable and sliceable. "Sequence" is better, and "Slice" or "Array" 
would be actually most recommended.


Andrei



 Jul 14 2015



  parent reply "Mike" <none none.com>  writes:


On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu 
wrote:


 STL's "sequential containers" do not have serial dependence on 
 items. There, "sequential" is meant as a converse of 
 "associative".


Indeed, but the term "sequence" has existed long before the STL 
authors (mis)used it.  Actually, 3 of the 5 main "sequence 
containers" *are* sequences.  The other 2, vector (which is 
another name that has always bothered me) and array, are really 
best described as a random-access containers, but the authors 
probably didn't want to split hairs and make another category.

My interpretation of the word "list" both in and out of the CS 
domain jives with random access.  Consider a stream.  I define it 
to be truly a "sequence" of bytes, specifically because of its 
serial nature.  I would definitely *not* define it as a "list" of 
bytes.

When we say "these items must be accessed in sequence", we imply 
that Item(n+1) should be accessed only after Item(n) is accessed.

In our nomenclature, we should probably look more to the origin 
of terms, and their usage in other domains, than their (mis)use 
in the CS domain, especially C++.

Mike



 Jul 14 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/14/15 5:13 PM, Mike wrote:

 On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu wrote:


 STL's "sequential containers" do not have serial dependence on items.
 There, "sequential" is meant as a converse of "associative".


 Indeed, but the term "sequence" has existed long before the STL authors
 (mis)used it.  Actually, 3 of the 5 main "sequence containers" *are*
 sequences.  The other 2, vector (which is another name that has always
 bothered me) and array, are really best described as a random-access
 containers, but the authors probably didn't want to split hairs and make
 another category.


All this is more proof it comes down to a judgment call. Yeah, vector is 
probably a bit off,


 My interpretation of the word "list" both in and out of the CS domain
 jives with random access.


Well mine doesn't.


 Consider a stream.  I define it to be truly a
 "sequence" of bytes, specifically because of its serial nature.  I would
 definitely *not* define it as a "list" of bytes.

 When we say "these items must be accessed in sequence", we imply that
 Item(n+1) should be accessed only after Item(n) is accessed.


I'm not seeing much of that assertion at 
https://en.wikipedia.org/wiki/Sequence or really wherever 
https://www.google.com/search?q=sequence takes you.


 In our nomenclature, we should probably look more to the origin of
 terms, and their usage in other domains, than their (mis)use in the CS
 domain, especially C++.


I disagree. Context, affinity, and familiarity are important. It is no 
secret that the design of D has had C++ as a major influence, and the 
design of Phobos has had STL as a major influence. Defining the "right" 
terminology will take us from one imperfect nomenclature to another 
imperfect one, just less familiar one.

Let's drop it. Again: arguments base on purity and precision of widely 
used terms are futile.


Andrei



 Jul 14 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/14/15 5:24 PM, Andrei Alexandrescu wrote:

 On 7/14/15 5:13 PM, Mike wrote:

 On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu wrote:


 STL's "sequential containers" do not have serial dependence on items.
 There, "sequential" is meant as a converse of "associative".


 Indeed, but the term "sequence" has existed long before the STL authors
 (mis)used it.  Actually, 3 of the 5 main "sequence containers" *are*
 sequences.  The other 2, vector (which is another name that has always
 bothered me) and array, are really best described as a random-access
 containers, but the authors probably didn't want to split hairs and make
 another category.


 All this is more proof it comes down to a judgment call. Yeah, vector is
 probably a bit off,


Sorry for the incomplete thought - easy to figure :o). -- Andrei



 Jul 14 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 14 July 2015 at 21:25:50 UTC, Andrei Alexandrescu 
wrote:

 On 7/14/15 5:24 PM, Andrei Alexandrescu wrote:

 All this is more proof it comes down to a judgment call. Yeah, 
 vector is
 probably a bit off,


 Sorry for the incomplete thought - easy to figure :o). -- Andrei


The one thing that's nice about the name vector as opposed to 
Array is that it's not going to be confused with the arrays in 
the language, which is way too easy to do with Array (especially 
in verbal conversation). Everyone who's used C++ much knows what 
you're talking about when you're talking about a vector as a 
container. But considering what a vector is outside of the STL, 
it's definitely an odd choice.

- Jonathan M Davis



 Jul 14 2015



prev sibling  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Monday, 13 July 2015 at 22:08:27 UTC, deadalnix wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template arguments are indexable, so "sequence" doesn't 
 quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Andrei


 Splat ? Would that work ?


Why not? If you feel auto-expansion is so important. As long as 
it's not "sequence"... Maybe clarify it by calling it 
"AliasSplat", in case we one day get other kinds of splats?



 Jul 14 2015



prev sibling next sibling parent  "Mike" <none none.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:


 What happened? Why are we replacing a crappy term with another 
 crappy term?



The opportunity is before you:  
https://github.com/D-Programming-Language/phobos/pull/3487



 Jul 13 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:


 What happened? Why are we replacing a crappy term with another 
 crappy term?


And by request, "AliasTuple":  
https://github.com/D-Programming-Language/phobos/pull/3488



 Jul 14 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/14/15 4:47 AM, Mike wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:


 What happened? Why are we replacing a crappy term with another crappy
 term?


 And by request, "AliasTuple":
 https://github.com/D-Programming-Language/phobos/pull/3488


I'd be okay with this, prolly more than AliasSeq. -- Andrei



 Jul 14 2015



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


Good to see another bad name merged in master ^_^



 Jul 15 2015



 next sibling parent reply "wobbles" <grogan.colin gmail.com>  writes:


On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


Personally, I'm ok with the name AliasTuple
Though I thought AliasSplat was good though...

Also, this seems like the longest bikeshedding thread yet, even 
longer than the official bikeshedding thread a couple weeks ago!



 Jul 15 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 07:59:49 UTC, wobbles wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Personally, I'm ok with the name AliasTuple
 Though I thought AliasSplat was good though...


Well if you forget for a moment that it is neither tuple (per 
std.typecons.Tuple semantics) nor limited to aliases... :D


 Also, this seems like the longest bikeshedding thread yet, even 
 longer than the official bikeshedding thread a couple weeks ago!


AFAIR it is third thread like that on this topic in last 2 or 3 
years.



 Jul 15 2015



  parent  "Daniel N" <ufo orbiting.us>  writes:


On Wednesday, 15 July 2015 at 08:05:59 UTC, Dicebot wrote:

 Well if you forget for a moment that it is neither tuple (per 
 std.typecons.Tuple semantics) nor limited to aliases... :D


My first association with 'Tuple' is that it's a heterogeneous 
structure, this is clearly a step up compared to other 
alternatives which were discussed such as 'Array' which 
traditionally are homogeneous.

Thus I'm in favour of this name.



 Jul 15 2015



prev sibling next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address>  writes:


On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


Yep, same feeling here....

--
Paolo



 Jul 15 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 15 July 2015 at 08:13:20 UTC, Paolo Invernizzi 
wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


At this point, I think that it's simply a question of which bad 
name we go with. None of them are particularly good, and there's 
a lot of disagreement about almost all of them - and if there's a 
lot of agreement, it's about how bad the name is, not how good it 
is.

I'd be very surprised to ever get real agreement on this. There 
simply isn't a good name for it. And if Walter and Andrei like 
AliasTuple, it's probably going to stick (and Andrei does seem to 
like it; no idea about Walter).

- Jonathan M Davis



 Jul 15 2015



  parent reply "Deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis 
wrote:

 On Wednesday, 15 July 2015 at 08:13:20 UTC, Paolo Invernizzi 
 wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


 At this point, I think that it's simply a question of which bad 
 name we go with. None of them are particularly good, and 
 there's a lot of disagreement about almost all of them - and if 
 there's a lot of agreement, it's about how bad the name is, not 
 how good it is.

 I'd be very surprised to ever get real agreement on this. There 
 simply isn't a good name for it. And if Walter and Andrei like 
 AliasTuple, it's probably going to stick (and Andrei does seem 
 to like it; no idea about Walter).

 - Jonathan M Davis


Tuple is the only name where we have actual, factual feedback. 
Hanging in the d irc chan for years, it is apparent that calling 
this tuple confuse people. That is a fact.



 Jul 15 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/15/15 9:28 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis wrote:

 On Wednesday, 15 July 2015 at 08:13:20 UTC, Paolo Invernizzi wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


 At this point, I think that it's simply a question of which bad name
 we go with. None of them are particularly good, and there's a lot of
 disagreement about almost all of them - and if there's a lot of
 agreement, it's about how bad the name is, not how good it is.

 I'd be very surprised to ever get real agreement on this. There simply
 isn't a good name for it. And if Walter and Andrei like AliasTuple,
 it's probably going to stick (and Andrei does seem to like it; no idea
 about Walter).

 - Jonathan M Davis


 Tuple is the only name where we have actual, factual feedback. Hanging
 in the d irc chan for years, it is apparent that calling this tuple
 confuse people. That is a fact.


It doesn't confuse me. We have type tuples and expression tuples defined 
in the spec. An alias tuple can have both expressions and types. It's 
not that confusing. What was confusing is that a TypeTuple was not a 
type tuple as defined in the spec.

All those tuples are already not the same as tuples as defined from 
other languages. So all three explanations are going to confuse some 
people. I don't think we can come up with a name that doesn't confuse 
some set of people.

This issue of naming this one thing is so long in the tooth, we need to 
just move on IMO.

-Steve



 Jul 15 2015



 next sibling parent reply "rsw0x" <anonymous anonymous.com>  writes:


On Wednesday, 15 July 2015 at 13:47:21 UTC, Steven Schveighoffer 
wrote:

 On 7/15/15 9:28 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis 
 wrote:

 [...]


 Tuple is the only name where we have actual, factual feedback. 
 Hanging
 in the d irc chan for years, it is apparent that calling this 
 tuple
 confuse people. That is a fact.


 It doesn't confuse me. We have type tuples and expression 
 tuples defined in the spec. An alias tuple can have both 
 expressions and types. It's not that confusing. What was 
 confusing is that a TypeTuple was not a type tuple as defined 
 in the spec.

 All those tuples are already not the same as tuples as defined 
 from other languages. So all three explanations are going to 
 confuse some people. I don't think we can come up with a name 
 that doesn't confuse some set of people.

 This issue of naming this one thing is so long in the tooth, we 
 need to just move on IMO.

 -Steve


To repeat what I already said, the issue is not the name but the 
documentation.

How many here have read the page on tuples?
http://dlang.org/tuple.html

Give it a read through and tell me you aren't confused as hell.



 Jul 15 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/15/15 9:54 AM, rsw0x wrote:

 On Wednesday, 15 July 2015 at 13:47:21 UTC, Steven Schveighoffer wrote:

 On 7/15/15 9:28 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis wrote:

 [...]


 Tuple is the only name where we have actual, factual feedback. Hanging
 in the d irc chan for years, it is apparent that calling this tuple
 confuse people. That is a fact.


 It doesn't confuse me. We have type tuples and expression tuples
 defined in the spec. An alias tuple can have both expressions and
 types. It's not that confusing. What was confusing is that a TypeTuple
 was not a type tuple as defined in the spec.

 All those tuples are already not the same as tuples as defined from
 other languages. So all three explanations are going to confuse some
 people. I don't think we can come up with a name that doesn't confuse
 some set of people.

 This issue of naming this one thing is so long in the tooth, we need
 to just move on IMO.


 To repeat what I already said, the issue is not the name but the
 documentation.

 How many here have read the page on tuples?
 http://dlang.org/tuple.html

 Give it a read through and tell me you aren't confused as hell.


That document needs to be rewritten. I don't consider it part of the 
spec per-se, but it's definitely out of date.

-Steve



 Jul 15 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 15:15:13 UTC, Steven Schveighoffer 
wrote:

 That document needs to be rewritten. I don't consider it part 
 of the spec per-se, but it's definitely out of date.


I had PR that did but it has a weird fate. Originally written 
with MetaList in mind, later update to Arguments, forgotten and 
abandoned and surprise-merged month later (when it was AliasSeq 
in Phobos already), taken care of by Mike now in a desperate 
attempt to keep it in sync with rename changes that keep being 
merged into Phobos.

Hint : this is exactly what is wrong with this whole thread.



 Jul 15 2015



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/15/15 11:19 AM, Dicebot wrote:

 On Wednesday, 15 July 2015 at 15:15:13 UTC, Steven Schveighoffer wrote:

 That document needs to be rewritten. I don't consider it part of the
 spec per-se, but it's definitely out of date.


 I had PR that did but it has a weird fate. Originally written with
 MetaList in mind, later update to Arguments, forgotten and abandoned and
 surprise-merged month later (when it was AliasSeq in Phobos already),
 taken care of by Mike now in a desperate attempt to keep it in sync with
 rename changes that keep being merged into Phobos.

 Hint : this is exactly what is wrong with this whole thread.


Yeah, I'm pretty much done arguing AT ALL about this. This is a whole 
lot of discussion for something that literally can be typed in 2 seconds 
if you need a new name for it:

alias MyFunkyName(T...) = T;

-Steve



 Jul 15 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 9:47 AM, Steven Schveighoffer wrote:

 On 7/15/15 9:28 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis wrote:

 On Wednesday, 15 July 2015 at 08:13:20 UTC, Paolo Invernizzi wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


 At this point, I think that it's simply a question of which bad name
 we go with. None of them are particularly good, and there's a lot of
 disagreement about almost all of them - and if there's a lot of
 agreement, it's about how bad the name is, not how good it is.

 I'd be very surprised to ever get real agreement on this. There simply
 isn't a good name for it. And if Walter and Andrei like AliasTuple,
 it's probably going to stick (and Andrei does seem to like it; no idea
 about Walter).

 - Jonathan M Davis


 Tuple is the only name where we have actual, factual feedback. Hanging
 in the d irc chan for years, it is apparent that calling this tuple
 confuse people. That is a fact.


 It doesn't confuse me. We have type tuples and expression tuples defined
 in the spec. An alias tuple can have both expressions and types. It's
 not that confusing. What was confusing is that a TypeTuple was not a
 type tuple as defined in the spec.


I agree.

Andrei



 Jul 15 2015



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 15:29:25 UTC, Andrei Alexandrescu 
wrote:

 It doesn't confuse me. We have type tuples and expression 
 tuples defined
 in the spec. An alias tuple can have both expressions and 
 types. It's
 not that confusing. What was confusing is that a TypeTuple was 
 not a
 type tuple as defined in the spec.


 I agree.

 Andrei


I want to point out that statement "an alias tuple can have both 
expressions and types" is somewhat between imprecise and just 
wrong with current compiler implementation. `X!(42, int, foo)` 
doesn't hold aliases to value, type and symbol (assuming X(T...)) 
- it does hold actual value and type, with only symbol being 
aliased. Actual alias tuple would be defined as `X(alias a, alias 
b, alias c)` and is somewhat different thing.

You may want to ignore that difference for simplicity sake but it 
needs to be explicitly acknowledged.



 Jul 15 2015



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/15/2015 05:35 PM, Dicebot wrote:

 On Wednesday, 15 July 2015 at 15:29:25 UTC, Andrei Alexandrescu wrote:

 It doesn't confuse me. We have type tuples and expression tuples defined
 in the spec. An alias tuple can have both expressions and types. It's
 not that confusing. What was confusing is that a TypeTuple was not a
 type tuple as defined in the spec.


 I agree.

 Andrei


 I want to point out that statement "an alias tuple can have both
 expressions and types" is somewhat between imprecise and just wrong with
 current compiler implementation. `X!(42, int, foo)` doesn't hold aliases
 to value, type and symbol (assuming X(T...)) - it does hold actual value
 and type, with only symbol being aliased. Actual alias tuple would be
 defined as `X(alias a, alias b, alias c)` and is somewhat different thing.

 You may want to ignore that difference for simplicity sake but it needs
 to be explicitly acknowledged.


It should instead be acknowledged that there /should/ be no difference 
in what three things can be passed to X(T...) and X(alias a, alias b, 
alias c). The X(T...) if(T.length==k) pattern is ridiculous.



 Jul 15 2015



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-07-15 23:44, Timon Gehr wrote:


 It should instead be acknowledged that there /should/ be no difference
 in what three things can be passed to X(T...) and X(alias a, alias b,
 alias c). The X(T...) if(T.length==k) pattern is ridiculous.


I completely agree.

-- 
/Jacob Carlborg



 Jul 15 2015



  parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Thursday, 16 July 2015 at 06:33:00 UTC, Jacob Carlborg wrote:

 On 2015-07-15 23:44, Timon Gehr wrote:


 It should instead be acknowledged that there /should/ be no 
 difference
 in what three things can be passed to X(T...) and X(alias a, 
 alias b,
 alias c). The X(T...) if(T.length==k) pattern is ridiculous.


 I completely agree.


Walter has agreed at DConf that this (i.e. alias not accepting 
basic types) should be fixed.

  — David



 Jul 16 2015



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/16/2015 03:45 PM, David Nadlinger wrote:

 On Thursday, 16 July 2015 at 06:33:00 UTC, Jacob Carlborg wrote:

 On 2015-07-15 23:44, Timon Gehr wrote:


 It should instead be acknowledged that there /should/ be no difference
 in what three things can be passed to X(T...) and X(alias a, alias b,
 alias c). The X(T...) if(T.length==k) pattern is ridiculous.


 I completely agree.


 Walter has agreed at DConf that this (i.e. alias not accepting basic
 types) should be fixed.

   — David


Ok, thanks! I have updated https://issues.dlang.org/show_bug.cgi?id=9029 
from enhancement request to bug report. (It should be noted that there 
were many other reports of the same issue.)



 Jul 16 2015



prev sibling next sibling parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote:

 It should instead be acknowledged that there /should/ be no 
 difference in what three things can be passed to X(T...) and 
 X(alias a, alias b, alias c). The X(T...) if(T.length==k) 
 pattern is ridiculous.


Yes, that would immediately solve the objection against "Alias" 
in the name, beside making the language more consistent.



 Jul 16 2015



prev sibling next sibling parent  "Adrian Matoga" <epi atari8.info>  writes:


On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote:

 It should instead be acknowledged that there /should/ be no 
 difference in what three things can be passed to X(T...) and 
 X(alias a, alias b, alias c). The X(T...) if(T.length==k) 
 pattern is ridiculous.


+1



 Jul 16 2015



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote:

 It should instead be acknowledged that there /should/ be no 
 difference in what three things can be passed to X(T...) and 
 X(alias a, alias b, alias c). The X(T...) if(T.length==k) 
 pattern is ridiculous.


I am all for that but it needs to be explicitly acknowledged and 
implemented together with a rename.



 Jul 16 2015



  parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Thursday, 16 July 2015 at 10:19:11 UTC, Dicebot wrote:

 I am all for that but it needs to be explicitly acknowledged 
 and implemented together with a rename.


There is no renaming involved here, as the issue concerns the 
alias parameter language constructs. Or are you suggesting using 
another keyword than "alias"?

  – David



 Jul 16 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 16 July 2015 at 13:48:06 UTC, David Nadlinger wrote:

 On Thursday, 16 July 2015 at 10:19:11 UTC, Dicebot wrote:

 I am all for that but it needs to be explicitly acknowledged 
 and implemented together with a rename.


 There is no renaming involved here, as the issue concerns the 
 alias parameter language constructs. Or are you suggesting 
 using another keyword than "alias"?

  – David


I mean that if name AliasSomething goes to 2.068, matching change 
to compiler argument lists must land in same release - and there 
must be a change log entry connecting and explaining those two.



 Jul 16 2015



  parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Thursday, 16 July 2015 at 14:38:09 UTC, Dicebot wrote:

 I mean that if name AliasSomething goes to 2.068, matching 
 change to compiler argument lists must land in same release - 
 and there must be a change log entry connecting and explaining 
 those two.


I disagree with that. These aren't related at all. The change 
would affect alias params, not argument lists (which already 
accept "everything").

  — David



 Jul 16 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 16 July 2015 at 14:40:16 UTC, David Nadlinger wrote:

 On Thursday, 16 July 2015 at 14:38:09 UTC, Dicebot wrote:

 I mean that if name AliasSomething goes to 2.068, matching 
 change to compiler argument lists must land in same release - 
 and there must be a change log entry connecting and explaining 
 those two.


 I disagree with that. These aren't related at all. The change 
 would affect alias params, not argument lists (which already 
 accept "everything").

  — David


We are arguing about a name for argument lists. For name 
'AliasSomething' to not be a lie, `T...` must be be absolutely 
identical to `alias a, alias b, ...` which currently is not the 
case.



 Jul 16 2015



  parent reply "Daniel N" <ufo orbiting.us>  writes:


On Thursday, 16 July 2015 at 14:44:23 UTC, Dicebot wrote:

 We are arguing about a name for argument lists. For name 
 'AliasSomething' to not be a lie, `T...` must be be absolutely 
 identical to `alias a, alias b, ...` which currently is not the 
 case.


We could just document that the compiler contains a bug in the 
current alias implementation, but AliasSomething is named after 
the specification of how alias must work. Then the alias fix can 
go into version +1.



 Jul 16 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 16 July 2015 at 15:21:01 UTC, Daniel N wrote:

 On Thursday, 16 July 2015 at 14:44:23 UTC, Dicebot wrote:

 We are arguing about a name for argument lists. For name 
 'AliasSomething' to not be a lie, `T...` must be be absolutely 
 identical to `alias a, alias b, ...` which currently is not 
 the case.


 We could just document that the compiler contains a bug in the 
 current alias implementation, but AliasSomething is named after 
 the specification of how alias must work. Then the alias fix 
 can go into version +1.


It will mean compiler bug will actually be fixed several years 
later and we will have another misleading dichotomy for that 
time. And most likely actual fix will be implemented with 
semantics different from ones originally discussed. I know how 
things work with D development.

Please, stop making compromises. It isn't politics. Outline 
issues, define constraints, reject partial solutions. Either 
stuff get fixed or it is better not touched at all until someone 
is ready to put in necessary effort.

Stop playing democrat. It is incompatible with open-source by 
design and only results in crappy technology.



 Jul 16 2015



  parent  "Dicebot" <public dicebot.lv>  writes:


On Thursday, 16 July 2015 at 15:29:41 UTC, Dicebot wrote:

 Stop playing democrat.


*democracy



 Jul 16 2015



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote:

 On 07/15/2015 05:35 PM, Dicebot wrote:

 On Wednesday, 15 July 2015 at 15:29:25 UTC, Andrei 
 Alexandrescu wrote:

 It doesn't confuse me. We have type tuples and expression 
 tuples defined
 in the spec. An alias tuple can have both expressions and 
 types. It's
 not that confusing. What was confusing is that a TypeTuple 
 was not a
 type tuple as defined in the spec.


 I agree.

 Andrei


 I want to point out that statement "an alias tuple can have 
 both
 expressions and types" is somewhat between imprecise and just 
 wrong with
 current compiler implementation. `X!(42, int, foo)` doesn't 
 hold aliases
 to value, type and symbol (assuming X(T...)) - it does hold 
 actual value
 and type, with only symbol being aliased. Actual alias tuple 
 would be
 defined as `X(alias a, alias b, alias c)` and is somewhat 
 different thing.

 You may want to ignore that difference for simplicity sake but 
 it needs
 to be explicitly acknowledged.


 It should instead be acknowledged that there /should/ be no 
 difference in what three things can be passed to X(T...) and 
 X(alias a, alias b, alias c). The X(T...) if(T.length==k) 
 pattern is ridiculous.


I can't agree more.



 Jul 17 2015



prev sibling  parent  "Deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 15 July 2015 at 15:29:25 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 9:47 AM, Steven Schveighoffer wrote:

 On 7/15/15 9:28 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 08:29:40 UTC, Jonathan M Davis 
 wrote:

 On Wednesday, 15 July 2015 at 08:13:20 UTC, Paolo Invernizzi 
 wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


 At this point, I think that it's simply a question of which 
 bad name
 we go with. None of them are particularly good, and there's 
 a lot of
 disagreement about almost all of them - and if there's a lot 
 of
 agreement, it's about how bad the name is, not how good it 
 is.

 I'd be very surprised to ever get real agreement on this. 
 There simply
 isn't a good name for it. And if Walter and Andrei like 
 AliasTuple,
 it's probably going to stick (and Andrei does seem to like 
 it; no idea
 about Walter).

 - Jonathan M Davis


 Tuple is the only name where we have actual, factual 
 feedback. Hanging
 in the d irc chan for years, it is apparent that calling this 
 tuple
 confuse people. That is a fact.


 It doesn't confuse me. We have type tuples and expression 
 tuples defined
 in the spec. An alias tuple can have both expressions and 
 types. It's
 not that confusing. What was confusing is that a TypeTuple was 
 not a
 type tuple as defined in the spec.


 I agree.

 Andrei


It is not about you guys. Yes this as defined in the spec, for 
the most part. Still people weere confused about it. That is a 
hard fact.

At this point, the specalso say what typetuple is, and, once 
you've gone through it, you understand what it is. Yet, we 
decided to change it because everyone was confused.

There are expectation that come with names.



 Jul 15 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/15/2015 1:13 AM, Paolo Invernizzi wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


Does this mean that complaining about the names I pick is going to die down? :-)



 Jul 17 2015



  parent  "Paolo Invernizzi" <paolo.invernizzi no.address>  writes:


On Friday, 17 July 2015 at 21:02:51 UTC, Walter Bright wrote:

 On 7/15/2015 1:13 AM, Paolo Invernizzi wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Yep, same feeling here....


 Does this mean that complaining about the names I pick is going 
 to die down? :-)


I'm +1 for Aliases!

--
Paolo



 Jul 20 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


Was there a good name suggested that wasn't vetoed by Walter or 
Andrei?



 Jul 15 2015



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 08:29:52 UTC, Mike wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Was there a good name suggested that wasn't vetoed by Walter or 
 Andrei?


For me it was absolutely clear that picking a good name is 
impossible even through the previous discussion (~1 year ago) 
because existing semantics is a mess and breaking it is out of 
question. Thus more realistic criteria is name consistency with 
some bit of fact correctness.

This was how original (Meta)List was chosen - being as bad as any 
other, it matched terms used by official compiler spec : 
http://dlang.org/template.html#TemplateParameterList 
http://dlang.org/template.html#TemplateArgumentList (and related 
docs)

It is mostly irrelevant though (as long as it is not 
fundamentally misleading) - the whole issue is not about picking 
a single name but major cleanup sweeps through dlang.org and 
Phobos ensuring it is all on same terms and any possible 
abmiguity is clearly explained.



 Jul 15 2015



  parent reply "Mike" <none none.com>  writes:


On Wednesday, 15 July 2015 at 09:32:07 UTC, Dicebot wrote:


 This was how original (Meta)List was chosen - being as bad as 
 any other, it matched terms used by official compiler spec : 
 http://dlang.org/template.html#TemplateParameterList 
 http://dlang.org/template.html#TemplateArgumentList (and 
 related docs)

 It is mostly irrelevant though (as long as it is not 
 fundamentally misleading) - the whole issue is not about 
 picking a single name but major cleanup sweeps through 
 dlang.org and Phobos ensuring it is all on same terms and any 
 possible abmiguity is clearly explained.


Your comment resonates with me.  Would TemplateArguments, 
TemplateArgs, or TemplateArgList make things any better in your 
opinion?

FYI, I didn't expect the AliasTuple PR to be merged so quickly.  
If that's as good as it gets, so be it, but I'd like to bring 
this discussion to a amicable end, and I don't mind submitting a 
couple more alternate PRs if will help those who have to make the 
final judgment call and bring this issue to a close.

Mike



 Jul 15 2015



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 7:39 AM, Mike wrote:

 FYI, I didn't expect the AliasTuple PR to be merged so quickly.


Me neither. Since the bikeshedding gates have been opened, let the flood 
subside a little before taking action. -- Andrei



 Jul 15 2015



  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 7/15/15 7:52 AM, Andrei Alexandrescu wrote:

 On 7/15/15 7:39 AM, Mike wrote:

 FYI, I didn't expect the AliasTuple PR to be merged so quickly.


 Me neither. Since the bikeshedding gates have been opened, let the flood
 subside a little before taking action. -- Andrei


Let's consider that this decision HAS to be made before 2.068 is 
released, we can't change the name again. So any delay for this delays that.

One option is to revert to TypeTuple for 2.068 and change the name later.

-Steve



 Jul 15 2015



prev sibling  parent  "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 11:39:23 UTC, Mike wrote:

 On Wednesday, 15 July 2015 at 09:32:07 UTC, Dicebot wrote:


 This was how original (Meta)List was chosen - being as bad as 
 any other, it matched terms used by official compiler spec : 
 http://dlang.org/template.html#TemplateParameterList 
 http://dlang.org/template.html#TemplateArgumentList (and 
 related docs)

 It is mostly irrelevant though (as long as it is not 
 fundamentally misleading) - the whole issue is not about 
 picking a single name but major cleanup sweeps through 
 dlang.org and Phobos ensuring it is all on same terms and any 
 possible abmiguity is clearly explained.


 Your comment resonates with me.  Would TemplateArguments, 
 TemplateArgs, or TemplateArgList make things any better in your 
 opinion?


TemplateArgumentList (and derivatives) was the name I was pushing 
for originally but I got a lot of feedback that such names are 
both long and put too much semantical pressure into something 
that is used for many different unrelated purposes. Which felt 
reasonable.

Again, name doesn't matter that much. What matters is someone 
putting effort into propagating it to all docs / derivative 
names. I did my turn for that and it got reverted - now everyone 
is back to square one discussing names. Something we already did 
(and much more) in 2013 when there was a sort of "tuple season" 
in NG.

Bikeshedding it over and over again with an expectation that next 
merged name will be "good enough" simply won't work.



 Jul 15 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 4:29 AM, Mike wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Was there a good name suggested that wasn't vetoed by Walter or Andrei?


s/good name/name that I like/

FTFY


Andrei



 Jul 15 2015



  parent reply "Brian Rogoff" <brogoff gmail.com>  writes:


On Wednesday, 15 July 2015 at 11:50:43 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 4:29 AM, Mike wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Was there a good name suggested that wasn't vetoed by Walter 
 or Andrei?


 s/good name/name that I like/


What makes a good name good?

Some people thought 'splat' sounded ridiculous, i.e., they didn't 
like it, but its use in PHP, Ruby, and other scripting operators, 
where it's really quite similar to its use in D, make it a 'good' 
candidate IMO. It doesn't have numerous alternative meanings in 
CS, like List/Tuple/Sequence, and its coinage is relatively 
recent, so recent that the Wiki entry 
https://en.wikipedia.org/wiki/Splat doesn't refer to its use as a 
term in programming yet. It's also short.

I liked 'Seq', because it is a bit ambiguous, unlike 'Tuple', 
which has the same meaning in many popular languages, but by most 
criteria 'Splat' is better.



 Jul 15 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 10:10 AM, Brian Rogoff wrote:

 On Wednesday, 15 July 2015 at 11:50:43 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 4:29 AM, Mike wrote:

 On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 Was there a good name suggested that wasn't vetoed by Walter or Andrei?


 s/good name/name that I like/


 What makes a good name good?


One litmus test I have is there's no need to explain the word with 
another word. For a brief time we had in D "invariant" for "immutable". 
We made the change when we figured we needed all too often to explain 
"invariant data means immutable data" to people.

Probably this won't be very useful here because the abstraction we 
describe is rather complex. I'd be happy with something that a dozen of 
folks around here agree isn't bad.


 Some people thought 'splat' sounded ridiculous, i.e., they didn't like
 it, but its use in PHP, Ruby, and other scripting operators, where it's
 really quite similar to its use in D, make it a 'good' candidate IMO. It
 doesn't have numerous alternative meanings in CS, like
 List/Tuple/Sequence, and its coinage is relatively recent, so recent
 that the Wiki entry https://en.wikipedia.org/wiki/Splat doesn't refer to
 its use as a term in programming yet. It's also short.

 I liked 'Seq', because it is a bit ambiguous, unlike 'Tuple', which has
 the same meaning in many popular languages, but by most criteria 'Splat'
 is better.


If there's consensus for splat, I'm fine allowing it. I'm personally not 
very convinced because I'd never heard of the term before and (as I 
described) I was unable to discover with google what it means.


Andrei



 Jul 15 2015



  parent  "Brian Rogoff" <brogoff gmail.com>  writes:


On Wednesday, 15 July 2015 at 15:33:53 UTC, Andrei Alexandrescu 
wrote:

 Probably this won't be very useful here because the abstraction 
 we describe is rather complex. I'd be happy with something that 
 a dozen of folks around here agree isn't bad.


I sense that the disdain for 'splat' was on account of its use as 
onomatopeia. I understand, and thought the same thing at first 
(reminded me of the old Batman TV series: Bam! Boffo! Splat!) but 
we get used to anything.


 If there's consensus for splat, I'm fine allowing it. I'm 
 personally not very convinced because I'd never heard of the 
 term before and (as I described) I was unable to discover with 
 google what it means.


'splat operator' is how I'd Google it. If you're familiar with 
Ruby or PHP you'll see that terminology. Coffeescript too; here's 
an SO entry that gets the idea across

http://stackoverflow.com/questions/6201657/what-does-splats-mean-in-the-coffeescript-tutorial



 Jul 15 2015



prev sibling next sibling parent  "rsw0x" <anonymous anonymous.com>  writes:


On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote:

 Good to see another bad name merged in master ^_^


I don't mind AliasTuple, TypeTuple implied it could only contain 
types.

The main issue is that the documentation for tuples is incredibly 
confusing.



 Jul 15 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


So now we're at AliasTuple? -- Andrei



 Jul 15 2015



 next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 15 July 2015 at 11:49:46 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 So now we're at AliasTuple? -- Andrei


Well at least I have noticed notification about that being merged 
into Phobos master in my mailbox. I was not following this thread 
itself much.



 Jul 15 2015



prev sibling  parent reply "Deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 15 July 2015 at 11:49:46 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 So now we're at AliasTuple? -- Andrei


Please go for splat. It turns out it is used by functional guy, 
in various scripting languages and in the compiler backend 
communities.

The thing we are trying to name is a splat.

Also, I don't have any veto, but if I had one, tuple would get 
it. I've been hanging around for a while and seen so many being 
confused by d tuples that persisting in that direction would be a 
religious decision.



 Jul 15 2015



 next sibling parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 15-Jul-2015 16:32, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 11:49:46 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 So now we're at AliasTuple? -- Andrei


 Please go for splat. It turns out it is used by functional guy, in
 various scripting languages and in the compiler backend communities.

 The thing we are trying to name is a splat.


Seems like the best option w.r.t. naming things what they are.
Silly or not silly it's established and not confusing.


-- 
Dmitry Olshansky



 Jul 15 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 9:32 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 11:49:46 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 So now we're at AliasTuple? -- Andrei


 Please go for splat. It turns out it is used by functional guy, in
 various scripting languages and in the compiler backend communities.

 The thing we are trying to name is a splat.


These google searches returned no meaningful results:

splat
splat data structure
splat type
splat computer science

I did find a few relevant results with:

splat functional languages
splat scripting languages

Let's not inflate each new name idea to alleged popularity it doesn't 
really enjoy.


 Also, I don't have any veto, but if I had one, tuple would get it. I've
 been hanging around for a while and seen so many being confused by d
 tuples that persisting in that direction would be a religious decision.


For this coming release we've opened the naming to a somewhat democratic 
process. Walter and my plan was to let everyone discuss, then approve 
the consensus. We jokingly/worriedly remarked that all the cries "but we 
have consensus on a different name!" when there existed a perception of 
names being imposed will instantly go away. And so it did.

We won't be able to make progress if ten folks have eleven ideas about 
what's needed. People, choose AliasSeq, AliasTuple, or whatever the heck 
most of us agree upon, but let's just choose once and for good. There 
will be no turning back.


Andrei



 Jul 15 2015



 next sibling parent reply "Wyatt" <wyatt.epp gmail.com>  writes:


On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei Alexandrescu 
wrote:

 These google searches returned no meaningful results:


Try:
splat operator


 Let's not inflate each new name idea to alleged popularity it 
 doesn't really enjoy.


Having slept on it, I like splat because it IS relatively new as 
a named concept in our field.  Language is arbitrary, so we can 
do this and anyone confused can look it up.


 There will be no turning back.


Precisely.

-Wyatt



 Jul 15 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 11:48 AM, Wyatt wrote:

 On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei Alexandrescu wrote:

 These google searches returned no meaningful results:


 Try:
 splat operator


That doesn't come to mind when splat is used as a noun. -- Andrei



 Jul 15 2015



  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 15 July 2015 at 15:49:43 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 11:48 AM, Wyatt wrote:

 On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei 
 Alexandrescu wrote:

 These google searches returned no meaningful results:


 Try:
 splat operator


 That doesn't come to mind when splat is used as a noun. --


Yeah, "splat" as a name for an auto-expanding thingy would be a 
novelty. Ruby for instance doesn't have anything like that, it 
has a splat _operator_ (asterisk) to expand a normal array, or 
conversely, capture several arguments in one parameter.



 Jul 15 2015



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 12:09 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Wednesday, 15 July 2015 at 15:49:43 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 11:48 AM, Wyatt wrote:

 On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei Alexandrescu wrote:

 These google searches returned no meaningful results:


 Try:
 splat operator


 That doesn't come to mind when splat is used as a noun. --


 Yeah, "splat" as a name for an auto-expanding thingy would be a novelty.
 Ruby for instance doesn't have anything like that, it has a splat
 _operator_ (asterisk) to expand a normal array, or conversely, capture
 several arguments in one parameter.


So I'd say this is a strong argument against "splat". -- Andrei



 Jul 15 2015



  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Wed, Jul 15, 2015 at 02:21:54PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 7/15/15 12:09 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>"
 wrote:

On Wednesday, 15 July 2015 at 15:49:43 UTC, Andrei Alexandrescu wrote:

On 7/15/15 11:48 AM, Wyatt wrote:

On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei Alexandrescu wrote:

These google searches returned no meaningful results:


Try:
splat operator


That doesn't come to mind when splat is used as a noun. --


Yeah, "splat" as a name for an auto-expanding thingy would be a
novelty.  Ruby for instance doesn't have anything like that, it has a
splat _operator_ (asterisk) to expand a normal array, or conversely,
capture several arguments in one parameter.


 
 So I'd say this is a strong argument against "splat". -- Andrei


<joke>
Maybe we should call it AliasBeads. They have order, if you count them.
Put lines of beads together, and they form a new line, so they
"autoexpand". I know of no other programming language that uses this
term, so it's unique enough to cause people to think twice when using
it. Plus, it allows for lame jokes about losing your beads when you do
something wrong, or when the compiler has bugs that cause the beads to
behave erratically. :-P
</joke>


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson



 Jul 15 2015



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-07-15 18:09, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:


 Yeah, "splat" as a name for an auto-expanding thingy would be a novelty.
 Ruby for instance doesn't have anything like that, it has a splat
 _operator_ (asterisk) to expand a normal array, or conversely, capture
 several arguments in one parameter.


I'm not sure what should count as auto-expanding, but this works in Ruby:

a, b = [1, 2]

No extra operator is required in this case.

-- 
/Jacob Carlborg



 Jul 15 2015



  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 15 July 2015 at 19:52:39 UTC, Jacob Carlborg wrote:

 On 2015-07-15 18:09, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:


 Yeah, "splat" as a name for an auto-expanding thingy would be 
 a novelty.
 Ruby for instance doesn't have anything like that, it has a 
 splat
 _operator_ (asterisk) to expand a normal array, or conversely, 
 capture
 several arguments in one parameter.


 I'm not sure what should count as auto-expanding, but this 
 works in Ruby:

 a, b = [1, 2]

 No extra operator is required in this case.


What I meant is that there is no equivalent to the behaviour of 
TypeTuples:

     assert(is(TypeTuple!(int, float, TypeTuple!(string, int)) ==
               TypeTuple!(int, float, string, int));
     TypeTuple!(int, int) a;
     a[0] = 1; a[1] = 2;
     void foo(int, int);
     foo(a); // works

But not in Ruby:

     [1, 2, [3, 4]] != [1, 2, 3, 4]
     def foo a, b ; end
     foo([1, 2]);  // doesn't work
     foo(*[1, 2]); // but works with splat operator

Maybe auto-flattening is a better name for this behaviour?

My point is that there is no type in Ruby that is inherently 
"splatty", rather it's the operator that produces this behaviour. 
Therefore, "splat" is not used as a noun to signify such a type.



 Jul 16 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 08:00:43 UTC, Marc Schütz wrote:

 My point is that there is no type in Ruby that is inherently 
 "splatty", rather it's the operator that produces this 
 behaviour. Therefore, "splat" is not used as a noun to signify 
 such a type.


Yes, please forget about the tongue-in-cheek slang-term "splat".  
That's for kids!

"splat" is just slang for "asterisk"-something:

https://en.wikipedia.org/wiki/Asterisk

«In Commodore (and related) filesystems, an asterisk appearing 
next to a filename in a directory listing denotes an improperly 
closed file, commonly called a "splat file."»

«Certain categories of character types in role-playing games are 
called splats, and the game supplements describing them are 
called splatbooks. This usage originated with the shorthand 
"*book" for this type of supplement[…]»

«In many MUDs and MOOs, as well as "male", "female", and other 
more esoteric genders, there is a gender called "splat", which 
uses an asterisk to replace the letters that differ in standard 
English gender pronouns. For example, h* is used rather than him 
or her.»

You might as well call it "AliasGoo".



 Jul 16 2015



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2015-07-16 10:00, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:


 What I meant is that there is no equivalent to the behaviour of TypeTuples:

      assert(is(TypeTuple!(int, float, TypeTuple!(string, int)) ==
                TypeTuple!(int, float, string, int));
      TypeTuple!(int, int) a;
      a[0] = 1; a[1] = 2;
      void foo(int, int);
      foo(a); // works

 But not in Ruby:

      [1, 2, [3, 4]] != [1, 2, 3, 4]
      def foo a, b ; end
      foo([1, 2]);  // doesn't work
      foo(*[1, 2]); // but works with splat operator

 Maybe auto-flattening is a better name for this behaviour?

 My point is that there is no type in Ruby that is inherently "splatty",
 rather it's the operator that produces this behaviour. Therefore,
 "splat" is not used as a noun to signify such a type.


I see what you mean now.

-- 
/Jacob Carlborg



 Jul 16 2015



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 08:00:43 UTC, Marc Schütz wrote:

 Maybe auto-flattening is a better name for this behaviour?


"flattening": concatenating all the children recursively.

"argument unpacking"/"expansion": filling in the actual parameters

Anyway, auto-flattening is undesirable as it makes the language 
more weakly typed and hides what goes on. And it gets in the way 
for structural pattern matching. But those issues are off-topic, 
I guess.



 Jul 16 2015



prev sibling  parent reply "Deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 15 July 2015 at 15:28:11 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 9:32 AM, Deadalnix wrote:

 On Wednesday, 15 July 2015 at 11:49:46 UTC, Andrei 
 Alexandrescu wrote:

 On 7/15/15 3:50 AM, Dicebot wrote:

 Good to see another bad name merged in master ^_^


 So now we're at AliasTuple? -- Andrei


 Please go for splat. It turns out it is used by functional 
 guy, in
 various scripting languages and in the compiler backend 
 communities.

 The thing we are trying to name is a splat.


 These google searches returned no meaningful results:

 splat
 splat data structure
 splat type
 splat computer science

 I did find a few relevant results with:

 splat functional languages
 splat scripting languages

 Let's not inflate each new name idea to alleged popularity it 
 doesn't really enjoy.


I'm not inflating popularity (you'll have hard time quoting me 
doing fo, so please don't. Words have precise meaning).

This is not a popular word because this is not a popular 
construct to begin with. Yet this word is used to describe what 
we have here.

A newcomer would have either no expectation of what this 
construct is because he doesn't know the word (still better than 
tuple or list that come with the wrong expectation) or know the 
word and know what to expect.


 Also, I don't have any veto, but if I had one, tuple would get 
 it. I've
 been hanging around for a while and seen so many being 
 confused by d
 tuples that persisting in that direction would be a religious 
 decision.


 For this coming release we've opened the naming to a somewhat 
 democratic process. Walter and my plan was to let everyone 
 discuss, then approve the consensus. We jokingly/worriedly 
 remarked that all the cries "but we have consensus on a 
 different name!" when there existed a perception of names being 
 imposed will instantly go away. And so it did.

 We won't be able to make progress if ten folks have eleven 
 ideas about what's needed. People, choose AliasSeq, AliasTuple, 
 or whatever the heck most of us agree upon, but let's just 
 choose once and for good. There will be no turning back.


 Andrei


That how I ended up with seq in the first place. I went to talk 
to everybody and sequence was what came up the most while not 
having people as opposed to it as list.

What the majority come up with is different from everyone's first 
choice (seq isn't even my first choice). On the other hand, the 
recent change looks like a coup.



 Jul 15 2015



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 11:54 AM, Deadalnix wrote:

 That how I ended up with seq in the first place. I went to talk to
 everybody and sequence was what came up the most while not having people
 as opposed to it as list.


Now I'm sorry I even started. I'd be happy to return to AliasSeq. -- Andrei



 Jul 15 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 15 July 2015 at 18:21:10 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 11:54 AM, Deadalnix wrote:

 That how I ended up with seq in the first place. I went to 
 talk to
 everybody and sequence was what came up the most while not 
 having people
 as opposed to it as list.


 Now I'm sorry I even started. I'd be happy to return to 
 AliasSeq. -- Andrei


LOL. Yeah. Naming discussions always seem to go like this. 
Sometimes, a better name does come out of it, but even if it 
does, there's just way too much in the way of discussion to wade 
through, and it's not generally the most pleasant either. 
Certainly, it's pretty much never intellectually stimulating. :|

- Jonathan M Davis



 Jul 15 2015



prev sibling next sibling parent  "Colin" <grogan.colin gmail.com>  writes:


On Wednesday, 15 July 2015 at 18:21:10 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 11:54 AM, Deadalnix wrote:

 That how I ended up with seq in the first place. I went to 
 talk to
 everybody and sequence was what came up the most while not 
 having people
 as opposed to it as list.


 Now I'm sorry I even started. I'd be happy to return to 
 AliasSeq. -- Andrei


Luckily we have 2 people that can just decide.
I reckon at this stage yourself and Walter should just pick the 
name ye prefer best and go with it.

The democratic approach, I feel anyway, hasn't worked in this 
case... (Doesn't mean it wont in future!!)



 Jul 15 2015



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/15/2015 08:21 PM, Andrei Alexandrescu wrote:

 On 7/15/15 11:54 AM, Deadalnix wrote:

 That how I ended up with seq in the first place. I went to talk to
 everybody and sequence was what came up the most while not having people
 as opposed to it as list.


 Now I'm sorry I even started. I'd be happy to return to AliasSeq. -- Andrei


+1.



 Jul 15 2015



prev sibling  parent  "Daniel N" <ufo orbiting.us>  writes:


On Wednesday, 15 July 2015 at 15:54:17 UTC, Deadalnix wrote:

 This is not a popular word because this is not a popular 
 construct to begin with. Yet this word is used to describe what 
 we have here.


Thanks to the wonderful ambiguity of natural languages, it's 
quite likely that a number of people will think splat is a verb 
because it's spelled identically to the noun. Those people would 
expect it to splat things, such as arrays etc. Which it doesn't, 
it's actually functions closer to identity than splat.

Also newcomers looking for something which can handle undefined 
heterogeneous things, are not likely to search the documentation 
for Splat. Tuple is far likelier to be found.



 Jul 15 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
wrote:

 What happened? Why are we replacing a crappy term with another 
 crappy term?


Here's my interpretation of the current state of this as I read 
this thread
1. "AliasSeq" is no good as evident from the first post that 
started this thread
2. "AliasList" draws veto from decision makers due to list 
semantics in C++
3. "AliasTuple" draws both support and disdain, but at least 
there's some support.  Also, I volunteered to wordsmith the 
documentation on this, and I found myself a little dumbstruck 
yesterday trying to explain it.
4. "AliasSplat" uses a frivolous and slang term for the asterisk 
operator so is hard to take seriously, and like the other 
suggestions will require explanation.
5. "Arguments" isn't bad IMO, but it seems to draw disdain due to 
the fact that the construct in question may or may not be used 
for template arguments.

So, my asbestos underwear is on, and I ask if there is any 
support for the "CompileTimeEntityList".  I know it contains the 
'L'-word, so if you prefer consider "CompileTimeEntities".  If 
the length bothers you, then consider "CTEList" (could also be 
interpreted as Compile-time element list, I suppose).

I have one other suggestion, but I'd like to see how this goes 
first.  Given the current state of things, it appears that 
remaining silent or voicing disapproval without a viable 
suggestion is an implicit vote for "AliasTuple".

Mike



 Jul 15 2015



 next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/16/2015 02:49 AM, Mike wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:

 What happened? Why are we replacing a crappy term with another crappy
 term?


 Here's my interpretation of the current state of this as I read this thread
 1. "AliasSeq" is no good as evident from the first post that started
 this thread


Not at all evident. The only argument given in that post was not 
particularly valid.



 Jul 15 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:


 So, my asbestos underwear is on, and I ask if there is any 
 support for the "CompileTimeEntityList".  I know it contains 
 the 'L'-word, so if you prefer consider "CompileTimeEntities".  
 If the length bothers you, then consider "CTEList" (could also 
 be interpreted as Compile-time element list, I suppose).


I suppose "CompileTimeTuple" or "CTTuple" would be fine too, 
especially if we prefer to think of tuples as heterogeneous lists.



 Jul 15 2015



  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Jul 16, 2015 at 04:05:17AM +0000, Mike via Digitalmars-d wrote:

 On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:
 

So, my asbestos underwear is on, and I ask if there is any support
for the "CompileTimeEntityList".  I know it contains the 'L'-word, so
if you prefer consider "CompileTimeEntities".  If the length bothers
you, then consider "CTEList" (could also be interpreted as
Compile-time element list, I suppose).


 
 I suppose "CompileTimeTuple" or "CTTuple" would be fine too,
 especially if we prefer to think of tuples as heterogeneous lists.


"Tuple" was the original term used for this, and was also the term that
started the whole debate because people thought it implied something
that didn't fit in with how these things actually worked. It did not
help that Phobos also defines a "Tuple" type, with more "traditional"
tuple behaviour, that's based on this "TypeTuple" but different.
However, the names being so similar, people were confusing and
conflating the two, which led to all kinds of misunderstandings and
confusion.

If we're going to use any name with "Tuple" at all, we might as well
just admit defeat and go back to the original "TypeTuple" after all,
since nothing else seems to be any better.

I think any successful name is going to have to be outside the usual
suspects -- tuple, sequence, list, array, etc.. All of them have
connotations that don't apply to this thing, and all of them lead the
unwary to assume things about it that may not be correct. In fact,
"sequence" so far is probably the least evil of all the alternatives, if
only it weren't so long to spell out. I'm quite happy with AliasSeq, to
be honest, though some people hate gratuitous abbreviations. I think it
should just stay as AliasSeq, per Andrei's recent response.

But in any case, if people think AliasSeq is not good enough, then we
really have to think outside the box, because none of the usual
candidates are going to work. AliasBeads (that I jokingly suggested), or
AliasBraids, or ... various other silly names that kinda prove the point
that we'd better just stick with AliasSeq and call it a day, instead of
spending yet more time and energy on this long-dead horse.


T

-- 
That's not a bug; that's a feature!



 Jul 15 2015



prev sibling next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:

 On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu 
 wrote:

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Here's my interpretation of the current state of this as I read 
 this thread
 1. "AliasSeq" is no good as evident from the first post that 
 started this thread
 2. "AliasList" draws veto from decision makers due to list 
 semantics in C++
 3. "AliasTuple" draws both support and disdain, but at least 
 there's some support.  Also, I volunteered to wordsmith the 
 documentation on this, and I found myself a little dumbstruck 
 yesterday trying to explain it.
 4. "AliasSplat" uses a frivolous and slang term for the 
 asterisk operator so is hard to take seriously, and like the 
 other suggestions will require explanation.
 5. "Arguments" isn't bad IMO, but it seems to draw disdain due 
 to the fact that the construct in question may or may not be 
 used for template arguments.


You forgot "Aliases", which also was suggested.



 Jul 15 2015



prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 00:49:29 UTC, Mike wrote:

 2. "AliasList" draws veto from decision makers due to list 
 semantics in C++


Actually, "AliasList" is the most accurate term. "List" does not 
imply linked list in C++ or any other language I know of. C++ 
uses the term "list" for arguments. E.g:

va_list
std::forward_list
std::initializer_list

http://en.cppreference.com/mwiki/index.php?title=Special%3ASearch&search=list

(But keep it going, this thread is entertaining…)



 Jul 15 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 05:28:15 UTC, Ola Fosheim Grøstad 
wrote:

 std::forward_list


Forget that one, that actually would be a single linked list… :P 
And in C++ you also have "std::integer_sequence" for compile time 
parameters.

But I think "sequence" implies that everything has the same 
type...



 Jul 15 2015



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


Oh, here is one more term you can consider:

"AliasPack"

In Python "splatting" is called "unpacking" ("splat" refers to 
the visual impression of the "*" operator and is inappropriate).

C++ also have related use of the word "pack":

http://en.cppreference.com/w/cpp/language/parameter_pack

So in C++ all of the terms "list", "sequence" and "pack" can be 
used about parameter lists… but "list" is the general term: 
argument list, parameter list, initializer list etc…



 Jul 15 2015



 next sibling parent reply "Mike" <none none.com>  writes:


On Thursday, 16 July 2015 at 05:44:29 UTC, Ola Fosheim Grøstad 
wrote:


 C++ also have related use of the word "pack":

 http://en.cppreference.com/w/cpp/language/parameter_pack


Nice!  From the description:

"A template parameter pack is a template parameter that accepts 
zero or more template arguments (non-types, types, or templates). 
A function parameter pack is a function parameter that accepts 
zero or more function arguments.

A template with at least one parameter pack is called a variadic 
template."

Sound familiar?  I propose simply "Pack".

Mike



 Jul 15 2015



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote:

 Sound familiar?  I propose simply "Pack".


Or "AliasListPack", "AliasPackList", "PackedAliasList"…

(I'd hate to see the thread die…)



 Jul 15 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 05:55:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote:

 Sound familiar?  I propose simply "Pack".


 Or "AliasListPack", "AliasPackList", "PackedAliasList"…


Or would it be "UnpackingAliasList" or "UnpackedAliasList"? Oh… 
Headaches…



 Jul 15 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote:


 C++ also have related use of the word "pack":

 http://en.cppreference.com/w/cpp/language/parameter_pack


 I propose simply "Pack".


I know Ola is making light of this situation and many of you find 
this discussion beneath you, but we need a name, and with the 
release looming we need it relatively soon.

I've creating a pull request for "Pack" 
(https://github.com/D-Programming-Language/phobos/pull/3494) 
which is inspired by C++'s parameter_pack as linked in the 
previous post.

 From the description:
"A template parameter pack is a template parameter that accepts 
zero or more template arguments (non-types, types, or templates). 
A function parameter pack is a function parameter that accepts 
zero or more function arguments.
A template with at least one parameter pack is called a variadic 
template."

Given that that D has its roots in C++ and this construct is 
similar to the one in question, it seems like a good fit.

I prefer `Pack` over `AliasPack` or other variations because it's 
more general and allows us to be more specific in the future with 
`TypePack`, `ExpressionPack`, `AliasPack`, etc... later, but I'll 
be happy to change it if that's what you all wish.

Ultimately, though, it's going to be a judgment call, and I hope 
having a pull request ready to go makes things easier on those 
who have to make the call.  If it doesn't work, you know where 
the close button is.

Mike



 Jul 16 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 07:30:19 UTC, Mike wrote:

 I know Ola is making light of this situation and many of you 
 find this discussion beneath you, but we need a name, and with 
 the release looming we need it relatively soon.


Naming is difficult, but "list" and "pack" (alluding to 
unpacking) are the most accurate terms.

But you need a general term that covers both types and 
values/expressions... I don't know of one. "alias" is not an 
abstraction but more like an action that binds something. Maybe 
something like "mixed"…

Just "Pack" would be confusing... Sounds like a verb and I 
wouldn't understand it without looking it up in the docs. You 
need a word before "pack".

These I would be able to infer from context:

"MixedList"
"CompileTimeList"
"CTList"
"AliasList"
"AliasPack"
"ParamPack"
"ArgPack"
"Parameters"
"Arguments"


 Given that that D has its roots in C++ and this construct is 
 similar to the one in question, it seems like a good fit.


Yes, if C++ integration is going to big thing for D, it sounds 
reasonable to use similar terminology. Searching on 
cppreference.com is useful.



 Jul 16 2015



prev sibling next sibling parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote:

 On Thursday, 16 July 2015 at 05:44:29 UTC, Ola Fosheim Grøstad 
 wrote:


 C++ also have related use of the word "pack":

 http://en.cppreference.com/w/cpp/language/parameter_pack


 Nice!  From the description:

 "A template parameter pack is a template parameter that accepts 
 zero or more template arguments (non-types, types, or 
 templates). A function parameter pack is a function parameter 
 that accepts zero or more function arguments.

 A template with at least one parameter pack is called a 
 variadic template."

 Sound familiar?  I propose simply "Pack".


Only that it is in fact an UnPack...



 Jul 16 2015



prev sibling  parent  "Adrian Matoga" <epi atari8.info>  writes:


On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote:


 "A template parameter pack is a template parameter that accepts 
 zero or more template arguments (non-types, types, or 
 templates). A function parameter pack is a function parameter 
 that accepts zero or more function arguments.

 A template with at least one parameter pack is called a 
 variadic template."

 Sound familiar?  I propose simply "Pack".


+ 1



 Jul 16 2015



prev sibling  parent reply "Deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 16 July 2015 at 05:44:29 UTC, Ola Fosheim Grøstad 
wrote:

 Oh, here is one more term you can consider:

 "AliasPack"

 In Python "splatting" is called "unpacking" ("splat" refers to 
 the visual impression of the "*" operator and is inappropriate).

 C++ also have related use of the word "pack":

 http://en.cppreference.com/w/cpp/language/parameter_pack

 So in C++ all of the terms "list", "sequence" and "pack" can be 
 used about parameter lists… but "list" is the general term: 
 argument list, parameter list, initializer list etc…


Pack was my first choice, but it did seem to stick amongst the 
community when I asked around. I'd be happy with pack.



 Jul 16 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 17:10:57 UTC, Deadalnix wrote:

 On Thursday, 16 July 2015 at 05:44:29 UTC, Ola Fosheim Grøstad 
 wrote:

 Oh, here is one more term you can consider:

 "AliasPack"

 In Python "splatting" is called "unpacking" ("splat" refers to 
 the visual impression of the "*" operator and is 
 inappropriate).

 C++ also have related use of the word "pack":

 http://en.cppreference.com/w/cpp/language/parameter_pack

 So in C++ all of the terms "list", "sequence" and "pack" can 
 be used about parameter lists… but "list" is the general term: 
 argument list, parameter list, initializer list etc…


 Pack was my first choice, but it did seem to stick amongst the 
 community when I asked around. I'd be happy with pack.


FWIW, just like "Nat" often is used to denote natural numbers, 
"Seq" is often used in formalizations of sequences, e.g. stuff 
that falls under this definition:

https://en.wikipedia.org/wiki/Sequence#Formal_definition

So "AliasSeq" is counter-intuitive to me, it does not fit with 
any use of the term "Seq" I have been in touch with...

Basically, to me "Seq" represent series of values, not 
"configurations".



 Jul 16 2015



prev sibling  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/16/2015 07:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 16 July 2015 at 05:28:15 UTC, Ola Fosheim Grøstad wrote:

 std::forward_list


 Forget that one, that actually would be a single linked list… :P And in
 C++ you also have "std::integer_sequence" for compile time parameters.

 But I think "sequence" implies that everything has the same type...


That common "type" is 'alias'. :-)



 Jul 16 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 21:44:13 UTC, Timon Gehr wrote:

 On 07/16/2015 07:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:


[...]

 But I think "sequence" implies that everything has the same 
 type...


 That common "type" is 'alias'. :-)


*cringe*



 Jul 16 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that started
 this thread


I am egging my face for starting this. Can we please return to AliasSeq? 
-- Andrei



 Jul 16 2015



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Jul 16, 2015 at 11:50:25AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 7/15/15 8:49 PM, Mike wrote:

1. "AliasSeq" is no good as evident from the first post that started
this thread


 
 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


Yes, let's please return to AliasSeq. It's a pretty lousy name, but all
the alternatives are even worse. Let's not fix the problem by making it
worse.


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble
again.



 Jul 16 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/16/15 11:59 AM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Jul 16, 2015 at 11:50:25AM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that started
 this thread


 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 Yes, let's please return to AliasSeq. It's a pretty lousy name, but all
 the alternatives are even worse. Let's not fix the problem by making it
 worse.


WE HAVE CONSENSUS! :o)

(Well... anyone else in favor?)


Andrei



 Jul 16 2015



 next sibling parent  "Daniel N" <ufo orbiting.us>  writes:


On Thursday, 16 July 2015 at 16:13:46 UTC, Andrei Alexandrescu 
wrote:

 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 Yes, let's please return to AliasSeq. It's a pretty lousy 
 name, but all
 the alternatives are even worse. Let's not fix the problem by 
 making it
 worse.


 WE HAVE CONSENSUS! :o)

 (Well... anyone else in favor?)


 Andrei


Yes.

(It is far down on my list of preferred choices, but it is still 
on the half which is _endurable_.)



 Jul 16 2015



prev sibling next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 16:13:46 UTC, Andrei Alexandrescu 
wrote:

 WE HAVE CONSENSUS! :o)

 (Well... anyone else in favor?)


You should ask if anyone is against if you want consensus.



 Jul 16 2015



prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Thursday, 16 July 2015 at 16:13:46 UTC, Andrei Alexandrescu 
wrote:

 On 7/16/15 11:59 AM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Jul 16, 2015 at 11:50:25AM -0400, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 Yes, let's please return to AliasSeq. It's a pretty lousy 
 name, but all
 the alternatives are even worse. Let's not fix the problem by 
 making it
 worse.


 WE HAVE CONSENSUS! :o)

 (Well... anyone else in favor?)


Yes, me. ;)

  — David



 Jul 16 2015



 next sibling parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Thursday, 16 July 2015 at 17:39:13 UTC, David Nadlinger wrote:

 Yes, me. ;)


(I should note that this is mainly because I'd really rather not 
have "Tuple" in the name because of first-hand experience in 
teaching beginners both on IRC and in person. And AliasSeq seems 
like the most likely candidate for this right now. I personally 
like Seq quite a bit too, but I'd rather not join that 
bikeshedding debate. —David)



 Jul 16 2015



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/16/2015 07:50 PM, David Nadlinger wrote:

 On Thursday, 16 July 2015 at 17:39:13 UTC, David Nadlinger wrote:

 Yes, me. ;)


 (I should note that this is mainly because I'd really rather not have
 "Tuple" in the name because of first-hand experience in teaching
 beginners both on IRC and in person. And AliasSeq seems like the most
 likely candidate for this right now. I personally like Seq quite a bit
 too, but I'd rather not join that bikeshedding debate. —David)


Indeed. I will just write one of the following lines.

import std.meta:Seq=AliasSeq;
alias Seq(T...)=T;



 Jul 16 2015



prev sibling  parent  "ZombineDev" <valid_email he.re>  writes:


On Thursday, 16 July 2015 at 17:39:13 UTC, David Nadlinger wrote:

 On Thursday, 16 July 2015 at 16:13:46 UTC, Andrei Alexandrescu 
 wrote:

 On 7/16/15 11:59 AM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Jul 16, 2015 at 11:50:25AM -0400, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post 
 that started
 this thread


 I am egging my face for starting this. Can we please return 
 to
 AliasSeq? -- Andrei


 Yes, let's please return to AliasSeq. It's a pretty lousy 
 name, but all
 the alternatives are even worse. Let's not fix the problem by 
 making it
 worse.


 WE HAVE CONSENSUS! :o)

 (Well... anyone else in favor?)


 Yes, me. ;)

  — David


+1 for AliasSeq



 Jul 16 2015



prev sibling  parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 16-Jul-2015 19:13, Andrei Alexandrescu wrote:

 On 7/16/15 11:59 AM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Jul 16, 2015 at 11:50:25AM -0400, Andrei Alexandrescu via
 Digitalmars-d wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that started
 this thread


 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 Yes, let's please return to AliasSeq. It's a pretty lousy name, but all
 the alternatives are even worse. Let's not fix the problem by making it
 worse.


 WE HAVE CONSENSUS! :o)

 (Well... anyone else in favor?)


Fine by me.
Being the one who merged that pull in the first place I'm somewhat biased...


-- 
Dmitry Olshansky



 Jul 16 2015



  parent  Suliman <evermind live.ru>  writes:


So AliasSeq = Tuples?



 Sep 20 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei


https://github.com/D-Programming-Language/phobos/pull/3498



 Jul 16 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 16 July 2015 at 23:54:30 UTC, Mike wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
 wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei


 https://github.com/D-Programming-Language/phobos/pull/3498


Well this was 214 replies of wasted time...



 Jul 16 2015



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Fri, Jul 17, 2015 at 12:08:41AM +0000, Tofu Ninja via Digitalmars-d wrote:

 On Thursday, 16 July 2015 at 23:54:30 UTC, Mike wrote:

On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu wrote:

On 7/15/15 8:49 PM, Mike wrote:

1. "AliasSeq" is no good as evident from the first post that
started this thread


I am egging my face for starting this. Can we please return to
AliasSeq?  -- Andrei


https://github.com/D-Programming-Language/phobos/pull/3498


 
 Well this was 214 replies of wasted time...


Doesn't that describe a disturbingly large number of threads on this
forum? ;-)


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener



 Jul 16 2015



  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Friday, 17 July 2015 at 00:15:55 UTC, H. S. Teoh wrote:

 Doesn't that describe a disturbingly large number of threads on 
 this forum? ;-)


 T


Yes...... yes it does......



 Jul 16 2015



prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Friday, 17 July 2015 at 00:08:42 UTC, Tofu Ninja wrote:

 Well this was 214 replies of wasted time...


Just b/c the outcome is the same doesn't mean the discussion was 
pointless.
We reached at least some sort of consensus which should prevent 
any future complaints about the chosen name.



 Jul 17 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Friday, 17 July 2015 at 10:15:05 UTC, Martin Nowak wrote:

 On Friday, 17 July 2015 at 00:08:42 UTC, Tofu Ninja wrote:

 Well this was 214 replies of wasted time...


 Just b/c the outcome is the same doesn't mean the discussion 
 was pointless.
 We reached at least some sort of consensus which should prevent 
 any future complaints about the chosen name.


No, you did not reach consensus, and there will be future 
complaints about the terminology used in D (unless the language 
dies). If you pick inconsistent terminology that breaks 
established usage, people will complain…

So it was wasted time. And more time will be wasted the same way, 
due to a lack of process.

If you want consistency you need 2-4 people who know the field 
really well and reach actual consensus. When too many people who 
don't know the field really well are involved you get bastardized 
syntax.

The vocabulary should not be defined name by name, function by 
function. It should be, you know, an index that you can 
reference. So a set is a set, a sequence is a sequence, and array 
an array, a list a list, a linked-list a linked-list and so on.

A well designed language has a small vocabulary with not much 
overlap and expressiveness grow out of it. That way you don't 
have to memorize so much.

If you need to read the docs to deduce what goes on in a function 
then it isn't good enough. Which is why constructs with weird 
behaviour should have longer descriptive names.

In this case, you wanted a short unique name to describe weird 
behaviour. That's going to make code hard to read.



 Jul 17 2015



prev sibling  parent  "wobbles" <grogan.colin gmail.com>  writes:


On Friday, 17 July 2015 at 10:15:05 UTC, Martin Nowak wrote:

 On Friday, 17 July 2015 at 00:08:42 UTC, Tofu Ninja wrote:

 Well this was 214 replies of wasted time...


 Just b/c the outcome is the same doesn't mean the discussion 
 was pointless.
 We reached at least some sort of consensus which should prevent 
 any future complaints about the chosen name.


On that, perhaps this conversation should be linked to in the 
wiki before it gets buried? So any complains/questions may be 
directed here?



 Jul 17 2015



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/16/15 8:08 PM, Tofu Ninja wrote:

 On Thursday, 16 July 2015 at 23:54:30 UTC, Mike wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that started
 this thread


 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 https://github.com/D-Programming-Language/phobos/pull/3498


 Well this was 214 replies of wasted time...


That's right, and I'm at fault. Apologies to all. -- Andrei



 Jul 17 2015



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 23:54:30 UTC, Mike wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
 wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei


 https://github.com/D-Programming-Language/phobos/pull/3498


Please don't cry, there are so many other bad names in the 
eco-system already. Nobody will notice… unless they have a CS 
degree.



 Jul 16 2015



prev sibling next sibling parent  "Deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei






 Jul 17 2015



prev sibling  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei


What about the Pack name? There was considerable support for it, 
and at least in this thread I haven't seen anyone opposing it.

(And from my POV, *Seq is really the worst of all choices, as it 
has connotations in everyday language and other uses in 
mathematics that don't match TypeTuples at all, so I'm strongly 
opposed to it.)



 Jul 17 2015



  parent reply "Daniel N" <ufo orbiting.us>  writes:


On Friday, 17 July 2015 at 08:57:26 UTC, Marc Schütz wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
 wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return to 
 AliasSeq? -- Andrei


 What about the Pack name? There was considerable support for 
 it, and at least in this thread I haven't seen anyone opposing 
 it.

 (And from my POV, *Seq is really the worst of all choices, as 
 it has connotations in everyday language and other uses in 
 mathematics that don't match TypeTuples at all, so I'm strongly 
 opposed to it.)


FWIW

Pack > Seq



 Jul 17 2015



  parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com>  writes:


On Friday, 17 July 2015 at 09:13:13 UTC, Daniel N wrote:

 On Friday, 17 July 2015 at 08:57:26 UTC, Marc Schütz wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu 
 wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that 
 started
 this thread


 I am egging my face for starting this. Can we please return 
 to AliasSeq? -- Andrei


 What about the Pack name? There was considerable support for 
 it, and at least in this thread I haven't seen anyone opposing 
 it.

 (And from my POV, *Seq is really the worst of all choices, as 
 it has connotations in everyday language and other uses in 
 mathematics that don't match TypeTuples at all, so I'm 
 strongly opposed to it.)


 FWIW

 Pack > Seq


Sack (a compromise between Seq and Pack)



 Jul 17 2015



  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 17-Jul-2015 12:52, Matthias Bentrup wrote:

 On Friday, 17 July 2015 at 09:13:13 UTC, Daniel N wrote:

 On Friday, 17 July 2015 at 08:57:26 UTC, Marc Schütz wrote:

 On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu wrote:

 On 7/15/15 8:49 PM, Mike wrote:

 1. "AliasSeq" is no good as evident from the first post that started
 this thread


 I am egging my face for starting this. Can we please return to
 AliasSeq? -- Andrei


 What about the Pack name? There was considerable support for it, and
 at least in this thread I haven't seen anyone opposing it.

 (And from my POV, *Seq is really the worst of all choices, as it has
 connotations in everyday language and other uses in mathematics that
 don't match TypeTuples at all, so I'm strongly opposed to it.)


 FWIW

 Pack > Seq


 Sack (a compromise between Seq and Pack)


Ransack must be the first algorithm on AliasSack ;)

-- 
Dmitry Olshansky



 Jul 17 2015



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-07-07 23:16, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names.
 Template arguments are indexable, so "sequence" doesn't quite apply.

 What happened? Why are we replacing a crappy term with another crappy term?


How about "Bag" or "AliasBag"?

-- 
/Jacob Carlborg



 Jul 15 2015



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 06:32:15 UTC, Jacob Carlborg wrote:

 On 2015-07-07 23:16, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good 
 names.
 Template arguments are indexable, so "sequence" doesn't quite 
 apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 How about "Bag" or "AliasBag"?


A "bag" is the same as a C++ multi-set.

Let's go over the common usage:

"list": finite ordered source of entities

"tuple": in math it is a fixed length list of values, in 
programming it usually has semantics close to a record/struct 
with numbers instead of field names and structural typing.

"sequence": infinite or finite list of values of the same 
kind/type

"bag": unordered list

"set": bag with unique entities

"array": run-time indexable bag



 Jul 16 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 16 July 2015 at 07:14:34 UTC, Ola Fosheim Grøstad 
wrote:

 "array": run-time indexable bag


Eh... not bag, bag often means value semantics without identity...

"array": run-time indexable collection of entities.



 Jul 16 2015



prev sibling  parent  "Andrea Fontana" <nospam example.com>  writes:


On Thursday, 16 July 2015 at 06:32:15 UTC, Jacob Carlborg wrote:

 How about "Bag" or "AliasBag"?


Blob :)

"An object, especially a large one, having no distinct shape or 
definition"



 Jul 16 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/7/2015 2:16 PM, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good names. Template
 arguments are indexable, so "sequence" doesn't quite apply.

 What happened? Why are we replacing a crappy term with another crappy term?


Should just be "Aliases". I recall that my naming of "setExt()" was universally 
panned for using an abbreviation. "Aliases" doesn't carry any baggage about how 
it might be accessed.



 Jul 17 2015



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Fri, Jul 17, 2015 at 01:54:31PM -0700, Walter Bright via Digitalmars-d wrote:

 On 7/7/2015 2:16 PM, Andrei Alexandrescu wrote:

So I thought we were supposed to replace bad names with good names.
Template arguments are indexable, so "sequence" doesn't quite apply.

What happened? Why are we replacing a crappy term with another crappy
term?


 
 Should just be "Aliases". I recall that my naming of "setExt()" was
 universally panned for using an abbreviation. "Aliases" doesn't carry
 any baggage about how it might be accessed.


Wow, the bikeshedding truly never ends!


T

-- 
Дерево держится корнями, а человек -
друзьями.



 Jul 17 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 17 July 2015 at 20:59:41 UTC, H. S. Teoh wrote:

 On Fri, Jul 17, 2015 at 01:54:31PM -0700, Walter Bright via 
 Digitalmars-d wrote:

 On 7/7/2015 2:16 PM, Andrei Alexandrescu wrote:

So I thought we were supposed to replace bad names with good 
names. Template arguments are indexable, so "sequence" 
doesn't quite apply.

What happened? Why are we replacing a crappy term with 
another crappy term?


 
 Should just be "Aliases". I recall that my naming of 
 "setExt()" was universally panned for using an abbreviation. 
 "Aliases" doesn't carry any baggage about how it might be 
 accessed.


 Wow, the bikeshedding truly never ends!


 T


+1 , can we stop inserting coins in that machine every time it 
reach some kind of stable point (especially when this stable 
point is the same twice in a row ?)



 Jul 18 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <thecybershadow.lists gmail.com>  writes:


On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:

 I recall that my naming of "setExt()" was universally panned 
 for using an abbreviation.


No, it was because the abbreviation was the sole distinction from 
another function's name.



 Jul 17 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, 17 July 2015 at 21:22:00 UTC, Vladimir Panteleev wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:

 I recall that my naming of "setExt()" was universally panned 
 for using an abbreviation.


 No, it was because the abbreviation was the sole distinction 
 from another function's name.


Yeah. As long as abbreviations are reasonably clear they're 
actually a _good_ thing because they reduce code length without 
losing clarity. When you have multiword symbol names, they get 
ugly _really_ fast if you don't abbreviate. It's one of the 
things that tends to make Java code ugly; they frequently have 
overly long names because they don't abbreviate.

- Jonathan M Davis



 Jul 17 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


I'd be happy to do the pull request if you wish.



 Jul 17 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Saturday, 18 July 2015 at 00:20:23 UTC, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


Please no, Aliases is one of the worst names in the thread.



 Jul 17 2015



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


Here is a survey of all suggested names, please vote so we can 
end this with the best name...

http://goo.gl/forms/qls1ZGDCho



 Jul 17 2015



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we can 
 end this with the best name...

 http://goo.gl/forms/qls1ZGDCho


Small update, as of right now, there has been 45 responses to the 
survey, with AliasTuple in the lead.

Top 3 average rankings:
AliasTuple   3.16
Aliases      2.82
AliasList    2.76



 Jul 20 2015



 next sibling parent  "ixid" <adamsibson hotmail.com>  writes:


On Monday, 20 July 2015 at 08:18:46 UTC, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we can 
 end this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to 
 the survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


This is an excellent approach to bike-shedding. Is it appropriate 
now to ask people who object to AliasTuple to put those 
objections forward (specific problems with AliasTuple rather than 
'my name is better) and otherwise go forward with the term?



 Jul 20 2015



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/20/15 4:18 AM, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we can end
 this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to the
 survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


Heh, interesting. (I didn't vote in order to avoid influencing things, 
not that 1/45.0 matters that much.)

Where is AliasSeq?


Andrei



 Jul 20 2015



 next sibling parent  "wobbles" <grogan.colin gmail.com>  writes:


On Monday, 20 July 2015 at 13:09:06 UTC, Andrei Alexandrescu 
wrote:

 On 7/20/15 4:18 AM, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we 
 can end
 this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to 
 the
 survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


 Heh, interesting. (I didn't vote in order to avoid influencing 
 things, not that 1/45.0 matters that much.)

 Where is AliasSeq?


 Andrei


It's currently in 5th place on 2.38.

Full stats: 
https://docs.google.com/spreadsheets/d/1sFLQAYnI2Xx5CPrf9KXbuxUfdHPewyo67Y1Sb0Z8p5M/pubchart?oid=2030278607&format=interactive



 Jul 20 2015



prev sibling  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 20 July 2015 at 13:09:06 UTC, Andrei Alexandrescu 
wrote:

 On 7/20/15 4:18 AM, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we 
 can end
 this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to 
 the
 survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


 Heh, interesting. (I didn't vote in order to avoid influencing 
 things, not that 1/45.0 matters that much.)

 Where is AliasSeq?


 Andrei


2.38

You can see all the current results here, hover over a bar to see 
exact numbers
https://docs.google.com/spreadsheets/d/1sFLQAYnI2Xx5CPrf9KXbuxUfdHPewyo67Y1Sb0Z8p5M/pubchart?oid=2030278607&format=interactive



 Jul 20 2015



prev sibling  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 20 July 2015 at 08:18:46 UTC, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we can 
 end this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to 
 the survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


Whatever it means, the answers there don't seem to jive with the 
thread discussing it. In particular, AliasTuple probably has the 
strongest reaction against it out of any of the choices which 
have been seriously considered, based principly on all of the 
problems that we've had in explaining to people what on earth a 
TypeTuple is. The fact that Tuple is in the name has caused quite 
a few problems. So, seeing it on the top is a bit surprising. 
Though I wonder how many of the participants in the thread have 
responded to that, since many seem to just be sick of the 
discussion. More folks have responded to the survey though than 
have participated in the thread though.

- Jonathan M Davis



 Jul 20 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 20 July 2015 at 14:58:34 UTC, Jonathan M Davis wrote:

 Whatever it means, the answers there don't seem to jive with 
 the thread discussing it. In particular, AliasTuple probably 
 has the strongest reaction against it out of any of the choices 
 which have been seriously considered, based principly on all of 
 the problems that we've had in explaining to people what on 
 earth a TypeTuple is. The fact that Tuple is in the name has 
 caused quite a few problems. So, seeing it on the top is a bit 
 surprising. Though I wonder how many of the participants in the 
 thread have responded to that, since many seem to just be sick 
 of the discussion. More folks have responded to the survey 
 though than have participated in the thread though.

 - Jonathan M Davis


The ones against a name are vocal in the thread, the ones who 
don't mind it or like it tend to not be as vocal. The thread is 
not a good representation of what people like.



 Jul 20 2015



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Mon, Jul 20, 2015 at 03:33:14PM +0000, Tofu Ninja via Digitalmars-d wrote:

 On Monday, 20 July 2015 at 14:58:34 UTC, Jonathan M Davis wrote:

Whatever it means, the answers there don't seem to jive with the
thread discussing it. In particular, AliasTuple probably has the
strongest reaction against it out of any of the choices which have
been seriously considered, based principly on all of the problems
that we've had in explaining to people what on earth a TypeTuple is.
The fact that Tuple is in the name has caused quite a few problems.
So, seeing it on the top is a bit surprising. Though I wonder how
many of the participants in the thread have responded to that, since
many seem to just be sick of the discussion.  More folks have
responded to the survey though than have participated in the thread
though.

- Jonathan M Davis


 
 The ones against a name are vocal in the thread, the ones who don't
 mind it or like it tend to not be as vocal. The thread is not a good
 representation of what people like.


And there's also people like me, who have grown so sick and tired of
this endless bikeshedding (in spite of arriving at some sort of
"consensus" multiple times, only to be interrupted by Yet More
Proposals), that we simply don't even care to respond anymore, we just
want this thread to please just stop. At this point, even if we were to
name this thing AliasQwfdJskCmfpz, I would be OK with it, as long as
I don't see any more posts on this tiresome topic.

All of this energy could have been far more productively spent elsewhere
-- like improving the docs, or fixing the flood of new bugs on Bugzilla
where it has far more impact -- and yet here we are, prolonging this one
with no end in sight.

Andrei/Walter should just step in and make the final call on whatever
lousy name they wish (let's admit it, none of the names are any good,
and you ain't gonna please everybody no matter what), and let's just
move on.


T

-- 
your inconsistency is the only consistent thing about you! -- kd



 Jul 20 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/20/15 11:54 AM, H. S. Teoh via Digitalmars-d wrote:

 Andrei/Walter should just step in and make the final call on whatever
 lousy name they wish (let's admit it, none of the names are any good,
 and you ain't gonna please everybody no matter what), and let's just
 move on.


That's what we did a few times in the past. It did help with limiting 
discussions and revisionist pull requests, but not as much as anyone 
would have liked.

It seems to me that subjecting new names to some community scrutiny 
before freezing them forever is a sensible thing to do. The difficulties 
are finding good definitions for "community" and "scrutiny". And "some" 
:o). From what I can tell:

* For any name considered, there is at least one person who strongly 
believes is an epically bad choice and presents vivid anecdotes, 
similes, and parallels with other languages and domains to support that 
opinion.

* For most names considered, there is at least one person who is a 
strong advocate and is convinced that's by far a better choice than all 
others.

* Whatever choice we make, there's a sort of atmosphere that a radically 
better name is just around the corner and we'll all regret having 
freezing it.

* There's a sort of Warhol effect in that naming discussions are 
massive, therefore they must be important, therefore they garner 
attention, therefore they get more massive.

I had vague hopes some clarity would emerge from opening up the process. 
Sadly this is one of those "welcome to the club" results. What I do hope 
happens is more appreciation of all involved of the difficulty of making 
decisions and judgment calls in matters in which there's no telling 
right from wrong. Please, please, please cut Walter and me some slack in 
the future.

I'll talk to him today in the hope we'll be able to put an end to this.


Andrei



 Jul 20 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 20 July 2015 at 16:54:55 UTC, Andrei Alexandrescu 
wrote:

 On 7/20/15 11:54 AM, H. S. Teoh via Digitalmars-d wrote:

 Andrei/Walter should just step in and make the final call on 
 whatever
 lousy name they wish (let's admit it, none of the names are 
 any good,
 and you ain't gonna please everybody no matter what), and 
 let's just
 move on.


 That's what we did a few times in the past. It did help with 
 limiting discussions and revisionist pull requests, but not as 
 much as anyone would have liked.

 It seems to me that subjecting new names to some community 
 scrutiny before freezing them forever is a sensible thing to 
 do. The difficulties are finding good definitions for 
 "community" and "scrutiny". And "some" :o). From what I can 
 tell:

 * For any name considered, there is at least one person who 
 strongly believes is an epically bad choice and presents vivid 
 anecdotes, similes, and parallels with other languages and 
 domains to support that opinion.

 * For most names considered, there is at least one person who 
 is a strong advocate and is convinced that's by far a better 
 choice than all others.

 * Whatever choice we make, there's a sort of atmosphere that a 
 radically better name is just around the corner and we'll all 
 regret having freezing it.

 * There's a sort of Warhol effect in that naming discussions 
 are massive, therefore they must be important, therefore they 
 garner attention, therefore they get more massive.

 I had vague hopes some clarity would emerge from opening up the 
 process. Sadly this is one of those "welcome to the club" 
 results. What I do hope happens is more appreciation of all 
 involved of the difficulty of making decisions and judgment 
 calls in matters in which there's no telling right from wrong. 
 Please, please, please cut Walter and me some slack in the 
 future.

 I'll talk to him today in the hope we'll be able to put an end 
 to this.


 Andrei


Well, this time you did the exact reverse.

Consensus is reached, Andrei step in, we got 20 pages of 
bikesched to end up to square one, at which stage, Walter step in 
and put more coin into the jukebox.

Conclusion had been reached twice, and twice with the same name 
already. I feel like there is a kernel of people that just won't 
accept this, as the poll showed (I did not vote).

At some point, one have to accept that his proposal is not the 
one that will get in. My preference would go for Pack, then 
Splat, then Seq, but at this point I have to admit that the 
community does not share my taste. I expect others here to grow 
up a bit and accept that YOUR proposal is not gold platted, in 
fact, it is kind of shitty like all other proposal here. Deal 
with it.

Some of the proposals do not even make any sense. Come on, all 
people that got into this know how newcomer react to the Tuple 
name noticed the same reaction. Yet, there is a large crow of 
idiots (sorry if you are in that crowd, on that one you ARE an 
idiot) that will send that proposal in again and again. Anyone 
that proposed that name at this point should only be laughed at, 
as it is clearly the manifestation of someone that have not deal 
first hand with the problems of the historical name and is 
serving as a living example of Dunning Kruger.

Unless there is something significantly better then Seq, and that 
there is consensus on that fact it should be changed. I don't 
think any proposal, even the one I would prefer over Seq, match 
that criteria, and I don't think anything else honest here would 
either.

That is exhausting to come back here again and again just to 
argue the same point again and again. This must stop. Everybody 
else has better things to do.



 Jul 20 2015



 next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:


 I expect others here to grow up a bit



 Yet, there is a large crow of idiots (sorry if you are in that 
 crowd, on that one you ARE an idiot)


You trolling right now?



 Jul 21 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 21 July 2015 at 07:13:08 UTC, Tofu Ninja wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:


 I expect others here to grow up a bit



 Yet, there is a large crow of idiots (sorry if you are in that 
 crowd, on that one you ARE an idiot)


 You trolling right now?


I don't think that I'd say that he's trolling, but his anger 
clearly got the better of him.

I agree with the gist of what he said, though I certainly would 
not have said it the way that he did.

- Jonathan M Davis



 Jul 21 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 July 2015 at 07:13:08 UTC, Tofu Ninja wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:


 I expect others here to grow up a bit



 Yet, there is a large crow of idiots (sorry if you are in that 
 crowd, on that one you ARE an idiot)


 You trolling right now?


I'm not. I would certainly have put this in a nicer manner given 
different circumstance, and certainly should have. But the point 
remains.

There are facts. Fact is, several persons reported that actual, 
real life newcomer are confused by tuple. As the experiment is 
repeatable we are not dealing with in the anecdotal anymore.

The fact the the poll show this result as a first one tells us 
that a good chunk of voters are either unaware of the evidence 
(there is nothing wrong with being ignorant, but don't try to 
influence results when you are or you'll be received as it 
should, with ridicule) or willfully choose to ignore ignore them 
which is worse. This CANNOT be taken seriously.



 Jul 21 2015



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Tuesday, 21 July 2015 at 22:25:22 UTC, deadalnix wrote:

 I'm not. I would certainly have put this in a nicer manner 
 given different circumstance, and certainly should have. But 
 the point remains.

 There are facts. Fact is, several persons reported that actual, 
 real life newcomer are confused by tuple. As the experiment is 
 repeatable we are not dealing with in the anecdotal anymore.

 The fact the the poll show this result as a first one tells us 
 that a good chunk of voters are either unaware of the evidence 
 (there is nothing wrong with being ignorant, but don't try to 
 influence results when you are or you'll be received as it 
 should, with ridicule) or willfully choose to ignore ignore 
 them which is worse. This CANNOT be taken seriously.


All the poll shows is what people like(or hate the least), Walter 
and Andrei can interpret that how ever they wish. I am not 
arguing for or against any of the names(they all suck).

We get it, you think tuple is a bad name, you keep coming back 
and repeating the same arguments. Everyone gets it. But if people 
don't share in your opinion or don't think it is as bad as you 
make it out to be then they have that right, that does not make 
them ignorant or an idiot. Your ad hominem attacks are really not 
needed.

Personally I don't like tuple that much either, I would prefer 
AliasList, but I like it better than AliasSeq and far better than 
Aliases.



 Jul 21 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 July 2015 at 22:58:27 UTC, Tofu Ninja wrote:

 All the poll shows is what people like(or hate the least), 
 Walter and Andrei can interpret that how ever they wish. I am 
 not arguing for or against any of the names(they all suck).

 We get it, you think tuple is a bad name, you keep coming back 
 and repeating the same arguments. Everyone gets it. But if 
 people don't share in your opinion or don't think it is as bad 
 as you make it out to be then they have that right, that does 
 not make them ignorant or an idiot. Your ad hominem attacks are 
 really not needed.


Facts are not oppinions. Deal with it.



 Jul 21 2015



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Tuesday, 21 July 2015 at 23:06:51 UTC, deadalnix wrote:

 Facts are not oppinions. Deal with it.


It is fact that some people found the name TypeTuple confusing, 
nothing else.

You have the opinion that "tuple" should disqualify the name 
"AliasTuple", some clearly dont agree with that.

Why is this getting so toxic, it's just a name...



 Jul 21 2015



 next sibling parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Tue, Jul 21, 2015 at 11:27:01PM +0000, Tofu Ninja via Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 23:06:51 UTC, deadalnix wrote:

Facts are not oppinions. Deal with it.


 
 It is fact that some people found the name TypeTuple confusing,
 nothing else.
 
 You have the opinion that "tuple" should disqualify the name
 "AliasTuple", some clearly dont agree with that.
 
 Why is this getting so toxic, it's just a name...


Sounds like we need to invoke the bikeshedding equivalent of Godwin's
Law, right about now. :-P


T

-- 
Acid falls with the rain; with love comes the pain.



 Jul 21 2015



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 July 2015 at 23:27:03 UTC, Tofu Ninja wrote:

 On Tuesday, 21 July 2015 at 23:06:51 UTC, deadalnix wrote:

 Facts are not oppinions. Deal with it.


 It is fact that some people found the name TypeTuple confusing, 
 nothing else.

 You have the opinion that "tuple" should disqualify the name 
 "AliasTuple", some clearly dont agree with that.

 Why is this getting so toxic, it's just a name...


That is a very good question. The answer is because many are 
ready to waste everybody's time with uneducated opinion because 
"it is just a name".



 Jul 23 2015



prev sibling next sibling parent reply "Daniel N" <ufo orbiting.us>  writes:


On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

 Come on, all people that got into this know how newcomer react
 to the Tuple name noticed the same reaction.


No, that highly depends on the background of the newcomer, 
everyone I introduced D to , only found it confusing that it was 
named Type*.

Type* = A construct that powerful it can contain Type:s as well?

Whereas the intuitive meaning would be:

Type* = A construct that is limited to Type:s only.

Before this thread I didn't realize newcomers found the Tuple 
part confusing, I know that's the case now, but after viewing the 
poll, it seems to be a minority. But then again, how many 
newcomers would find Seq confusing, we will never know.



 Jul 21 2015



 next sibling parent  "Daniel N" <ufo orbiting.us>  writes:


On Tuesday, 21 July 2015 at 08:00:40 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

 Come on, all people that got into this know how newcomer react
 to the Tuple name noticed the same reaction.


 No, that highly depends on the background of the newcomer, 
 everyone I introduced D to , only found it confusing that it 
 was named Type*.

 Type* = A construct that powerful it can contain Type:s as well?

 Whereas the intuitive meaning would be:

 Type* = A construct that is limited to Type:s only.

 Before this thread I didn't realize newcomers found the Tuple 
 part confusing, I know that's the case now, but after viewing 
 the poll, it seems to be a minority. But then again, how many 
 newcomers would find Seq confusing, we will never know.


PS Ask yourself, how many of the new proposals contains *Type* ? 
Anyone was free to add such a proposal.

Even with our collective imagination, which spawned creative 
names such as OmniSplat?! Still exactly 0 of the new alternatives 
contained 'Type'. I ask again, which part of the name TypeTuple 
was bad?



 Jul 21 2015



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 July 2015 at 08:00:40 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

 Come on, all people that got into this know how newcomer react
 to the Tuple name noticed the same reaction.


 No, that highly depends on the background of the newcomer, 
 everyone I introduced D to , only found it confusing that it 
 was named Type*.

 Type* = A construct that powerful it can contain Type:s as well?

 Whereas the intuitive meaning would be:

 Type* = A construct that is limited to Type:s only.


Yes, that is very true. The "Type" part of the old name was 
confusing.


 Before this thread I didn't realize newcomers found the Tuple 
 part confusing, I know that's the case now, but after viewing 
 the poll, it seems to be a minority. But then again, how many 
 newcomers would find Seq confusing, we will never know.


Experience show that the tuple part of the old name was confusing 
as well.

The poll was not answered by newcomers but by users of this 
forum. Most of them are experienced D users and already know what 
to expect from the construct.



 Jul 21 2015



prev sibling  parent reply "Zoadian" <no no.no>  writes:


On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

 Some of the proposals do not even make any sense. Come on, all 
 people that got into this know how newcomer react to the Tuple 
 name noticed the same reaction. Yet, there is a large crow of 
 idiots (sorry if you are in that crowd, on that one you ARE an 
 idiot) that will send that proposal in again and again. Anyone 
 that proposed that name at this point should only be laughed 
 at, as it is clearly the manifestation of someone that have not 
 deal first hand with the problems of the historical name and is 
 serving as a living example of Dunning Kruger.


i get that TypeTuple is confusing as it is not _limited_ to types,
but why is it not a tuple?



 Jul 21 2015



  parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Tue, Jul 21, 2015 at 04:06:11PM +0000, Zoadian via Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

Some of the proposals do not even make any sense. Come on, all people
that got into this know how newcomer react to the Tuple name noticed
the same reaction. Yet, there is a large crow of idiots (sorry if you
are in that crowd, on that one you ARE an idiot) that will send that
proposal in again and again. Anyone that proposed that name at this
point should only be laughed at, as it is clearly the manifestation
of someone that have not deal first hand with the problems of the
historical name and is serving as a living example of Dunning Kruger.


 
 i get that TypeTuple is confusing as it is not _limited_ to types, but
 why is it not a tuple?


Because, among other things, it auto-expands.


T

-- 
PNP = Plug 'N' Pray



 Jul 21 2015



 next sibling parent reply "Zoadian" <no no.no>  writes:


On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 On Tue, Jul 21, 2015 at 04:06:11PM +0000, Zoadian via 
 Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote:

Some of the proposals do not even make any sense. Come on, 
all people that got into this know how newcomer react to the 
Tuple name noticed the same reaction. Yet, there is a large 
crow of idiots (sorry if you are in that crowd, on that one 
you ARE an idiot) that will send that proposal in again and 
again. Anyone that proposed that name at this point should 
only be laughed at, as it is clearly the manifestation of 
someone that have not deal first hand with the problems of 
the historical name and is serving as a living example of 
Dunning Kruger.


 
 i get that TypeTuple is confusing as it is not _limited_ to 
 types, but why is it not a tuple?


 Because, among other things, it auto-expands.


 T


I agree that auto-expansion is a bit unexpected (documentation 
does not even mention it...). But by that logic it's not a 
'Sequence', 'List' or 'Pack' either.

Can't we just call it Unpack!() then?



 Jul 21 2015



  parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Tue, Jul 21, 2015 at 05:55:41PM +0000, Zoadian via Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

On Tue, Jul 21, 2015 at 04:06:11PM +0000, Zoadian via Digitalmars-d wrote:




[...]

i get that TypeTuple is confusing as it is not _limited_ to types,
but why is it not a tuple?


Because, among other things, it auto-expands.


T


 
 I agree that auto-expansion is a bit unexpected (documentation does
 not even mention it...). But by that logic it's not a 'Sequence',
 'List' or 'Pack' either.
 
 Can't we just call it Unpack!() then?


[...]

This, and other similar proposals, have been already all been considered
in the past.  The conclusion was, and still is, that *none* of these
names are perfectly satisfactory. Prolonging this thread with new
proposals (that are actually just rehashes of long-dead proposals) isn't
getting us anywhere.

This is all missing the point, though, which is that we're wasting time
arguing over a miserable little identifier, when there are far more
important things we need to be working on right now. I wish we would
just call it Zxkuqyb and let it rest already.


T

-- 
For every argument for something, there is always an equal and opposite
argument against it. Debates don't give answers, only wounded or inflated egos.



 Jul 21 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 21 July 2015 at 18:15:08 UTC, H. S. Teoh wrote:

 I wish we would just call it Zxkuqyb and let it rest already.


If we're going to do something like that, why not go for the geek 
cred and go for XYZZY? ;)


 For every argument for something, there is always an equal and 
 opposite argument against it. Debates don't give answers, only 
 wounded or inflated egos.


This one doesn't seem as random as most of your quotes... 
Methinks that you rigged this one. :)

- Jonathan M Davis



 Jul 21 2015



  parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Tue, Jul 21, 2015 at 06:23:25PM +0000, Jonathan M Davis via Digitalmars-d
wrote:

 On Tuesday, 21 July 2015 at 18:15:08 UTC, H. S. Teoh wrote:

I wish we would just call it Zxkuqyb and let it rest already.


 
 If we're going to do something like that, why not go for the geek cred
 and go for XYZZY? ;)


Have you googled Zxkuqyb? ;-)



For every argument for something, there is always an equal and
opposite argument against it. Debates don't give answers, only
wounded or inflated egos.


 
 This one doesn't seem as random as most of your quotes... Methinks
 that you rigged this one. :)


[...]

Haha, actually, I didn't rig this one. My Perl script can sometimes be
surprisingly on-topic. But I think it's just a coincidence, since
usually when it's not on-topic nobody notices.


T

-- 
What doesn't kill me makes me stranger.



 Jul 21 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 21 July 2015 at 18:32:26 UTC, H. S. Teoh wrote:

 On Tue, Jul 21, 2015 at 06:23:25PM +0000, Jonathan M Davis via 
 Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 18:15:08 UTC, H. S. Teoh wrote:

I wish we would just call it Zxkuqyb and let it rest already.


 
 If we're going to do something like that, why not go for the 
 geek cred and go for XYZZY? ;)


 Have you googled Zxkuqyb? ;-)


Nope. That one does look pretty geeky too. Sadly, I've never 
played an Ultima game, which would be why I didn't catch the 
reference. Good stuff though.

- Jonathan M Davis



 Jul 21 2015



  parent  "Paolo Invernizzi" <paolo.invernizzi no.address>  writes:


On Tuesday, 21 July 2015 at 19:00:18 UTC, Jonathan M Davis wrote:

 On Tuesday, 21 July 2015 at 18:32:26 UTC, H. S. Teoh wrote:

 On Tue, Jul 21, 2015 at 06:23:25PM +0000, Jonathan M Davis via 
 Digitalmars-d wrote:

 On Tuesday, 21 July 2015 at 18:15:08 UTC, H. S. Teoh wrote:

I wish we would just call it Zxkuqyb and let it rest already.


 
 If we're going to do something like that, why not go for the 
 geek cred and go for XYZZY? ;)


 Have you googled Zxkuqyb? ;-)


 Nope. That one does look pretty geeky too. Sadly, I've never 
 played an Ultima game, which would be why I didn't catch the 
 reference. Good stuff though.

 - Jonathan M Davis


Lord British was by my side during all my electronic life...

---
Paolo, GM Tamer, Ultima Online, since beta!



 Jul 21 2015



prev sibling  parent reply "Daniel N" <ufo orbiting.us>  writes:


On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


1) .tupleof auto-expands and changing it at this point would 
cause epic breakage.(I also see no reason to.)

2) Even the tuple in std.typecons has a manual .expand property, 
i.e. it may not be auto-expanding but it reaffirms that expanding 
is a common operation on tuples.(the same is not true for arrays, 
lists, etc.)

3) At the risk of sounding like a broken record: Tuple is the 
poster-child of heterogeneous constructs.



 Jul 21 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 21 July 2015 at 21:26:24 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


 1) .tupleof auto-expands and changing it at this point would 
 cause epic breakage.(I also see no reason to.)


This is actually a very good point. First of, tupleof does not 
return a TypeTuple, but they have something similar in nature. 
This concept need a name, preferably a name that do not elicit 
confusion.

Even if we dodge the problem now by going for Aliases, this 
concept would still require a name. Using tuple for that concept 
just confuses people.


 2) Even the tuple in std.typecons has a manual .expand 
 property, i.e. it may not be auto-expanding but it reaffirms 
 that expanding is a common operation on tuples.(the same is not 
 true for arrays, lists, etc.)


If tuple have an .expand property, it is because the tuple and 
the expanded version of it are two different things.

This is confusing to name that thing a tuple as well. I do think 
this would be a mistake to name this anything like array or list 
as, if close, they are not quite the same and I suspect these 
name would elicit the same result as tuple does. That being said, 
I can only speculate for these, while I can assert it for tuple.


 3) At the risk of sounding like a broken record: Tuple is the 
 poster-child of heterogeneous constructs.


Yes, I know that strictly speaking, a tuple may well be auto 
expanding. But here you get into the Monad problem (ie: once you 
understand what a monad is, you loose all capacity to explain it 
to someone who don't).

There is the strict definition of the word, and there is what 
people expect out of it. When going academic, you want the first 
one. But, because you go for the first one, you end up saying 
things like "A monad is just a monoid in the category of 
endofunctors" which is certainly true, but won't help much when 
you try to actually use it.

It turns out that indeed, a tuple may well be auto expanding 
stricto sensu, but it is not what people expect of a tuple when 
they meet one.



 Jul 21 2015



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/22/2015 12:53 AM, deadalnix wrote:

 On Tuesday, 21 July 2015 at 21:26:24 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


 1) .tupleof auto-expands and changing it at this point would cause
 epic breakage.(I also see no reason to.)


 This is actually a very good point. First of, tupleof does not return a
 TypeTuple, but they have something similar in nature.


What's the difference? There shouldn't be any.



 Jul 21 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Wednesday, 22 July 2015 at 04:44:48 UTC, Timon Gehr wrote:

 On 07/22/2015 12:53 AM, deadalnix wrote:

 On Tuesday, 21 July 2015 at 21:26:24 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


 1) .tupleof auto-expands and changing it at this point would 
 cause
 epic breakage.(I also see no reason to.)


 This is actually a very good point. First of, tupleof does not 
 return a
 TypeTuple, but they have something similar in nature.


 What's the difference? There shouldn't be any.


You can't put runtime values into the first one, you can into the 
second one.



 Jul 23 2015



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/23/2015 10:42 AM, deadalnix wrote:

 On Wednesday, 22 July 2015 at 04:44:48 UTC, Timon Gehr wrote:

 On 07/22/2015 12:53 AM, deadalnix wrote:

 On Tuesday, 21 July 2015 at 21:26:24 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


 1) .tupleof auto-expands and changing it at this point would cause
 epic breakage.(I also see no reason to.)


 This is actually a very good point. First of, tupleof does not return a
 TypeTuple, but they have something similar in nature.


 What's the difference? There shouldn't be any.


 You can't put runtime values into the first one, you can into the second
 one.


It should be just a bunch of aliases to the field members, which have 
runtime values.

Anyway, I figured out the difference:

alias Seq(T...)=T;

void main(){
     struct S{ int x,y,z; }
     S s;
     alias a=s.tupleof; // error
     alias b=Seq!(s.x,s.y,s.z); // ok
     alias c=Seq!(s.tupleof); // ok
     typeof(s.tupleof) x;
     alias d=x; // ok
}


Wtf.



 Jul 23 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 23 July 2015 at 15:03:24 UTC, Timon Gehr wrote:

 On 07/23/2015 10:42 AM, deadalnix wrote:

 On Wednesday, 22 July 2015 at 04:44:48 UTC, Timon Gehr wrote:

 On 07/22/2015 12:53 AM, deadalnix wrote:

 On Tuesday, 21 July 2015 at 21:26:24 UTC, Daniel N wrote:

 On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote:

 Because, among other things, it auto-expands.


 T


 1) .tupleof auto-expands and changing it at this point 
 would cause
 epic breakage.(I also see no reason to.)


 This is actually a very good point. First of, tupleof does 
 not return a
 TypeTuple, but they have something similar in nature.


 What's the difference? There shouldn't be any.


 You can't put runtime values into the first one, you can into 
 the second
 one.


 It should be just a bunch of aliases to the field members, 
 which have runtime values.

 Anyway, I figured out the difference:

 alias Seq(T...)=T;

 void main(){
     struct S{ int x,y,z; }
     S s;
     alias a=s.tupleof; // error
     alias b=Seq!(s.x,s.y,s.z); // ok
     alias c=Seq!(s.tupleof); // ok
     typeof(s.tupleof) x;
     alias d=x; // ok
 }


 Wtf.


That definitely makes it seem like they _should_ be the same, 
though they clearly aren't. That may just be part of the issues 
related to alias not being consistent that David was bringing up 
before though. Regardless, I'm inclined to agree that what 
tupleof gives you should just be a TypeTuple/AliasSeq/whatever, 
though it would be nice to rename it once we actually settle on a 
name for the library construct.

- Jonathan M Davis



 Jul 23 2015



prev sibling  parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Monday, 20 July 2015 at 15:33:17 UTC, Tofu Ninja wrote:

 The ones against a name are vocal in the thread, the ones who 
 don't mind it or like it tend to not be as vocal. The thread is 
 not a good representation of what people like.


Neither is a superficial popularity contest a suitable indicator 
for good language design.

For example, there are substantial concerns regarding the 
teachability of names ending in "Tuple". While these are (by 
necessity) only backed by anecdotal evidence, several people made 
these observations when helping beginners. It would be foolish to 
ignore the experience we gained from the past in favor of an 
impromptu straw poll.

  — David



 Jul 20 2015



  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 20 July 2015 at 16:26:36 UTC, David Nadlinger wrote:

 On Monday, 20 July 2015 at 15:33:17 UTC, Tofu Ninja wrote:

 The ones against a name are vocal in the thread, the ones who 
 don't mind it or like it tend to not be as vocal. The thread 
 is not a good representation of what people like.


 Neither is a superficial popularity contest a suitable 
 indicator for good language design.


Didn't really claim that, just wanted to point out why the most 
popular names might not be obvious from the thread. I didn't mean 
to imply that the most popular = the best.


 For example, there are substantial concerns regarding the 
 teachability of names ending in "Tuple". While these are (by 
 necessity) only bcked by anecdotal evidence, several people 
 made these observations when helping beginners. It would be 
 foolish to ignore the experience we gained from the past in 
 favor of an impromptu straw poll.

  — David


It's already been pointed out that there is no obvious good name, 
just less bad names. While the most popular name has problems, so 
do all the others. At least we know now what is the most popular 
and Walter and Andrei can take that into account, and hopefully 
make deciding the best name a bit easier.

All arguments have been repeated... Just let Walter and Andrei 
decide and end this...



 Jul 20 2015



prev sibling  parent  "Atila Neves" <atila.neves gmail.com>  writes:


On Monday, 20 July 2015 at 14:58:34 UTC, Jonathan M Davis wrote:

 On Monday, 20 July 2015 at 08:18:46 UTC, Tofu Ninja wrote:

 On Saturday, 18 July 2015 at 01:05:20 UTC, Tofu Ninja wrote:

 Here is a survey of all suggested names, please vote so we 
 can end this with the best name...

 http://goo.gl/forms/qls1ZGDCho


 Small update, as of right now, there has been 45 responses to 
 the survey, with AliasTuple in the lead.

 Top 3 average rankings:
 AliasTuple   3.16
 Aliases      2.82
 AliasList    2.76


 Whatever it means, the answers there don't seem to jive with 
 the thread discussing it. In particular, AliasTuple probably 
 has the strongest reaction against it out of any of the choices 
 which have been seriously considered, based principly on all of 
 the problems that we've had in explaining to people what on 
 earth a TypeTuple is. The fact that Tuple is in the name has 
 caused quite a few problems. So, seeing it on the top is a bit 
 surprising. Though I wonder how many of the participants in the 
 thread have responded to that, since many seem to just be sick 
 of the discussion. More folks have responded to the survey 
 though than have participated in the thread though.

 - Jonathan M Davis


I suspect that many people, myself included, didn't have anything 
meaningful to add to the thread but still voted. Personally I 
didn't post because I didn't have a better idea for a name and I 
thought the proposed ones were all suboptimal.

Atila



 Jul 21 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


Let's get the "+1"s on this - please reply. I'm fine with Aliases with 
an extra umph that the BDFL favors it. -- Andrei



 Jul 17 2015



 next sibling parent  "Mike" <none none.com>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


+1



 Jul 17 2015



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


_Please_ no. It'll just make it extra confusing whether you're 
talking about what was TypeTuple or just aliases in general. 
That's why I've never liked the name Array for std.container. You 
always have to be extra careful when talking about it to make it 
clear what you mean, and if you're actually talking instead of 
writing, it's that much worse. And honestly, I wouldn't expect a 
type to have a name which was plural, and I'd expect the fact 
that it's plural would just increase the confusion. And 
TypeTuple, AliasSeq, whatever is already confusing enough as a 
concept without naming it something that adds confusion on its 
own.

- Jonathan M Davis



 Jul 17 2015



  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Saturday, 18 July 2015 at 01:44:27 UTC, Jonathan M Davis wrote:

 On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
 wrote:

 [...]


 _Please_ no. It'll just make it extra confusing whether you're 
 talking about what was TypeTuple or just aliases in general. 
 That's why I've never liked the name Array for std.container. 
 You always have to be extra careful when talking about it to 
 make it clear what you mean, and if you're actually talking 
 instead of writing, it's that much worse. And honestly, I 
 wouldn't expect a type to have a name which was plural, and I'd 
 expect the fact that it's plural would just increase the 
 confusion. And TypeTuple, AliasSeq, whatever is already 
 confusing enough as a concept without naming it something that 
 adds confusion on its own.

 - Jonathan M Davis


Yup.



 Jul 18 2015



prev sibling next sibling parent  "Xiaoxi" <xiaoxi 163.com>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


+1



 Jul 18 2015



prev sibling next sibling parent  Yazan D <invalid email.com>  writes:


On Fri, 17 Jul 2015 21:32:59 -0400, Andrei Alexandrescu wrote:


 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 
 Let's get the "+1"s on this - please reply. I'm fine with Aliases with
 an extra umph that the BDFL favors it. -- Andrei


+1



 Jul 18 2015



prev sibling next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


+1



 Jul 18 2015



prev sibling next sibling parent  "Daniel N" <ufo orbiting.us>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


+1



 Jul 18 2015



prev sibling next sibling parent  "Piotrek" <nodata nodata.pl>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


+1

The code would be just better to read and write with "Aliases".
To some extent I understand "confusion" point raised by others. 
However I not sure if it's overexaggerating.

Piotrek



 Jul 18 2015



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu 
wrote:

 On 7/17/15 8:20 PM, Mike wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:


 Should just be "Aliases".


 I'd be happy to do the pull request if you wish.


 Let's get the "+1"s on this - please reply. I'm fine with 
 Aliases with an extra umph that the BDFL favors it. -- Andrei


No it makes any oral discussion about it impossible to 
understand, as well as a good chunk of the spec.



 Jul 18 2015



prev sibling  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:

 On 7/7/2015 2:16 PM, Andrei Alexandrescu wrote:

 So I thought we were supposed to replace bad names with good 
 names. Template
 arguments are indexable, so "sequence" doesn't quite apply.

 What happened? Why are we replacing a crappy term with another 
 crappy term?


 Should just be "Aliases". I recall that my naming of "setExt()" 
 was universally panned for using an abbreviation. "Aliases" 
 doesn't carry any baggage about how it might be accessed.


Then you have the confusion about whether you're talking about 
the replacement of TypeTuple or just aliases in general - 
especially if verbal conversation. AliasSeq won't be confused 
with anything.

- Jonathan M Davis



 Jul 17 2015



 next sibling parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Saturday, 18 July 2015 at 01:35:03 UTC, Jonathan M Davis wrote:

 Then you have the confusion about whether you're talking about 
 the replacement of TypeTuple or just aliases in general - 
 especially if verbal conversation. AliasSeq won't be confused 
 with anything.

 - Jonathan M Davis


That's the beauty of it and why, years ago when having yet 
another conversation about renaming TypeTuple, I was highly in 
favor of the name Timon (if memory serves) had been using for 
awhile: Seq. The long, long conversations have shown that there's 
no simple combination of words that describes it well so a 
neologism is the best possible option if you want to avoid 
confusion.

You could argue that a new word is harder for beginners but I'd 
argue that using existing words in a way that doesn't actually 
describe it accurately or precisely is far worse. TypeTuple 
confused me greatly as a beginner. In this very NG archive you 
can find me suggesting, to my embarrassment, the name "Type List" 
as a replacement because I thought I understood what it was. The 
flood of disagreements is what finally made me dig in and 
understand it. While I think AliasSeq is better, it's not much 
better and suffers from the unrelated baggage that comes with 
"Alias" so I still think Seq is better than AliasSeq.

(I haven't read any of this thread because I'm exhausted with 
this topic so just ignore me if you guys have already rehashed 
and dismissed Seq. I don't care enough about the outcome anymore 
to fight for it.)



 Jul 17 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Saturday, 18 July 2015 at 02:07:42 UTC, Brad Anderson wrote:

 (I haven't read any of this thread because I'm exhausted with 
 this topic so just ignore me if you guys have already rehashed 
 and dismissed Seq. I don't care enough about the outcome 
 anymore to fight for it.)


It has been dismissed for semantic reasons... people just gloss 
over it.

"Seq" is a term that is used in formal specification in CS that 
usually means sequence-of-values-with-type(X). Sequence-of-ints, 
sequence-of-chars…

In general usage, "sequence" usually implies a series of values 
where distance/order is important for interpretation: 
DNA-sequence, Fibonacci-sequence, instruction-sequence, 
animation-sequence, sequences in music scores (time series in 
general), the output of generators (recurrence relations etc), 
etc.



 Jul 18 2015



prev sibling  parent reply "Sebastiaan Koppe" <mail skoppe.eu>  writes:


On Saturday, 18 July 2015 at 01:35:03 UTC, Jonathan M Davis wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:

 Should just be "Aliases"....


 Then you have the confusion about whether you're talking about 
 the replacement of TypeTuple or just aliases in general - 
 especially if verbal conversation. AliasSeq won't be confused 
 with anything.

 - Jonathan M Davis


I cannot think of one sentence that doesn't disambiguate.



 Jul 17 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Saturday, 18 July 2015 at 02:36:59 UTC, Sebastiaan Koppe wrote:

 On Saturday, 18 July 2015 at 01:35:03 UTC, Jonathan M Davis 
 wrote:

 On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote:

 Should just be "Aliases"....


 Then you have the confusion about whether you're talking about 
 the replacement of TypeTuple or just aliases in general - 
 especially if verbal conversation. AliasSeq won't be confused 
 with anything.

 - Jonathan M Davis


 I cannot think of one sentence that doesn't disambiguate.


Try changing the doc using it. Yes, if you think about it hard 
enough, you'll be able to figure out which is which, but overall, 
that makes the thing much harder ot read.



 Jul 18 2015