On Monday, 27 July 2015 at 20:47:08 UTC, Timon Gehr wrote:
> On 07/27/2015 10:12 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:
>>> On technical merit, AliasSeq is one of the better choices; it was what
>>> TypeTuple had been changed to prior to the recent,
>>
>> On technical merits "Seq" is one of the worst choices, let's not confuse
>> social dynamics with objectivity.
>>
>
> Your particular flavour of objectivity.

No. It means I can argue my point and provide references.

On 07/28/2015 05:23 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 27 July 2015 at 20:47:08 UTC, Timon Gehr wrote:
>> On 07/27/2015 10:12 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:
>>>> On technical merit, AliasSeq is one of the better choices; it was what
>>>> TypeTuple had been changed to prior to the recent,
>>>
>>> On technical merits "Seq" is one of the worst choices, let's not confuse
>>> social dynamics with objectivity.
>>>
>>
>> Your particular flavour of objectivity.
>
> No. It means I can argue my point and provide references.

There's a bootstrapping problem. It's not even clear what "objectivity" means here. You have not explicitly listed the criteria you were using and how you weighted them, neither have you made a convincing point for them nor provided relevant references. Unless I missed it, that is.

Anyway, it should be pretty clear that all proposed names are bad for some reasonable choice of "objectivity". If you want to avoid a bad name, suggest a good one.

On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:
> There's a bootstrapping problem. It's not even clear what "objectivity" means here.

It means there were no technical merits that lead to "Seq". Only social dynamics and psychology.

> If you want to avoid a bad name, suggest a good one.

Several acceptable ones have been suggested. And the argument against "AliasTuple" is weak given that you already have an unusual Tuple and that "Seq" is bound to break consistency.

I don't want to change a name. I want to see a sound design process that can lead to an enjoyable language.

On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:
> Martin has just merged the rename of `TypeTuple` to `AliasSeq` into the stable branch, which will be released soon. If anyone wants to change the name again, please open a PR immediately, this is the last chance.

Personally I like Arity.

But if we are going with AliasSeq can we at least use the full word AliasSequence.

IMOA:
AliasSeq on it's own seems an obscure word to describe what it is

On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:
> Anyway, it should be pretty clear that all proposed names are bad for some reasonable choice of "objectivity". If you want to avoid a bad name, suggest a good one.

I suggest we remove it without replacement.

The original intention from...
https://web.archive.org/web/20120111015958/http://dlang.org/tuple.html
... suggested that the user should declare their own 'Unspeakable'.(what I have been doing).

Unfortunately TypeTuple was made available without proper template constraints, due to the path of least resistance, people started using it for everything.

Surely it better, either to not change it at all, or to remove it rather than adding something most feel is bad?

On Tuesday, 28 July 2015 at 07:23:07 UTC, Sean Campbell wrote:
> On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:
>> Martin has just merged the rename of `TypeTuple` to `AliasSeq` into the stable branch, which will be released soon. If anyone wants to change the name again, please open a PR immediately, this is the last chance.
>
> Personally I like Arity.
>
> But if we are going with AliasSeq can we at least use the full word AliasSequence.
>
> IMOA:
> AliasSeq on it's own seems an obscure word to describe what it is

+1

I don't see the need to shorten it myself.

On Tuesday, 28 July 2015 at 07:57:36 UTC, Daniel N wrote:
> On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:
>> Anyway, it should be pretty clear that all proposed names are bad for some reasonable choice of "objectivity". If you want to avoid a bad name, suggest a good one.
>
> I suggest we remove it without replacement.
>
> The original intention from...
> https://web.archive.org/web/20120111015958/http://dlang.org/tuple.html
> ... suggested that the user should declare their own 'Unspeakable'.(what I have been doing).
>
> Unfortunately TypeTuple was made available without proper template constraints, due to the path of least resistance, people started using it for everything.
>
> Surely it better, either to not change it at all, or to remove it rather than adding something most feel is bad?

Template constraints? Why on earth would TypeTuple need template constraints? Because it was badly named and has Type in its name? It holds more than types and that's a _good_ thing. TypeTuple is incredibly useful - especially for unit testing, and forcing you to declare it yourself is just wasteful. We're definitely going to have it. It's just a question of what it's going to be called. And no one has a good name for it. Alias fits the bill far better than type, since essentially, it's a list of aliases, so we're definitely going with Alias in the name. It's just a question of what the second half of its name is, and Seq gives the fewest wrong preconceptions about what the thing is, which is why it was picked. It's still a sucky name, but _all_ of the names suck.

Regardless, we're definitely not getting rid of it. That would make no sense at all.

- Jonathan M Davis

On Tuesday, 28 July 2015 at 08:11:20 UTC, Jonathan M Davis wrote:
> Template constraints? Why on earth would TypeTuple need template constraints? Because it was badly named and has Type in its name? It holds more than types and that's a _good_ thing.

Yes, following the original intention, plain Tuple was the unconstrained version.

It has a perfectly find name given this definition from tuple.html:
"Type Tuples

If a tuple's elements are solely types, it is called a TypeTuple"

On Tuesday, 28 July 2015 at 08:11:20 UTC, Jonathan M Davis wrote:
> half of its name is, and Seq gives the fewest wrong preconceptions about what the thing is, which is why it was picked. It's still a sucky name, but _all_ of the names suck.

How do you know that it will give the fewest wrong preconceptions? For anyone that work with sequences it most certainly is doomed to give the wrong preconception.

Define a vocabulary with clean semantics for D and stick with it. If the only key difference between Tuple and TypeTuple is auto expansion, then change the semantics and add a separate construct for expansion.

On Monday, 27 July 2015 at 22:52:11 UTC, deadalnix wrote:
> On Monday, 27 July 2015 at 09:01:33 UTC, Marc Schütz wrote:
>> On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:
>>> AliasTuple in particular has serious issues with it from the perspective of teaching people what it is an how to use it, because it has Tuple in its name,
>>
>> People keep claiming that, but have never posted any evidence. We know that _TypeTuple_ had issues, but for all we know, the problem was the "Type" part, not the "Tuple" part.
>>
>
> We have various reports that are consistent and confirm this is an issue. At this point, this is a repeatable experiment, not an anecdote anymore. Ignoring repeatable experiment puts you in the tinfoil hat section of the population. You don't want to be there.

Well, your post kind of proves my point. You've stated this several times, and you mentioned that people had problems, but as evidence you only mentioned some obscure irc communications that - for all I know - no one except you has ever seen. Now, I could simply believe you there (after all you're a competent person), but... that's not very scientific at all. If you say that these are repeatable experiments, with a representative sample of the programming community (or even just beginners), with consistent outcomes, then I prefer to see evidence for these claims before I believe them. I'm therefore not ignoring experiments, I have doubts about the validity of said experiments.

> It is not ignored. It is simply that alternative proposal also have issues, and many of them have issues that are worse. No proposal was significantly better so that it reached any kind of consensus.
>
> No your personal favorite did not either.

I don't have a strong personal favourite, I just have a strong anti-favourite :-)