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.
Yep C# too: List<T> is arguably the most used collection in the 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 C# 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
 C#
 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
 C#
 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:
 On Th
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
I'm good with that. As said, not my #1 choice, but good enough.
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