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

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?

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

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.

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

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

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

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.

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

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.