On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
> On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari@hotmail.com> said:
>
>> On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
>>> I think it should be called either a "compile-time list" ...
>> 
>> And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
>
> Will .tupleof become .ctlistof?

This feature should be dropped and provided as library using compile time reflection.

On 08/22/2013 03:07 PM, deadalnix wrote:
> On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
>> On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari@hotmail.com> said:
>>
>>> On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
>>>> I think it should be called either a "compile-time list" ...
>>>
>>> And if we go with "compile-time list", then we can follow the example
>>> of std.regex.ctRegex and name the thing "ctList".
>>
>> Will .tupleof become .ctlistof?
>
> This feature should be dropped and provided as library using compile
> time reflection.

How to bypass protection attributes?

On Thursday, 22 August 2013 at 13:10:28 UTC, Timon Gehr wrote:
> On 08/22/2013 03:07 PM, deadalnix wrote:
>> On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
>>> On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari@hotmail.com> said:
>>>
>>>> On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
>>>>> I think it should be called either a "compile-time list" ...
>>>>
>>>> And if we go with "compile-time list", then we can follow the example
>>>> of std.regex.ctRegex and name the thing "ctList".
>>>
>>> Will .tupleof become .ctlistof?
>>
>> This feature should be dropped and provided as library using compile
>> time reflection.
>
> How to bypass protection attributes?

compile time reflection should be able to do it. Discussion has been raised many time.

On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:
> There's an inordinate amount of confusion around what we currently call "type tuple" (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years.
>
> So: shall we use "template pack" going forward exclusively whenever we refer to that stuff? That way we can unambiguously use "tuple" for "value tuples, i.e. like mini-structs that group values together".

I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple:

    TypeTuple!(int, string) myExpressionTuple;
    myExpressionTuple[0] = 42;
    myExpressionTuple[1] = "foo";
    // etc

If we don't have an easy way to refer to this distinction with the new naming, it may not be adequate enough for everyone to discard the old, confusing names, which could potentially seriously stall adoption, as it would be tempting to use the old terms in certain situations. We also have the naming of std.traits' `isTypeTuple` and `isExpressionTuple` to think about.

On a different tangent; changes like this are probably easier to push through when they have a strong air of officialness. Thank you for starting the process with this thread. An idea would be to have Walter and/or yourself (Andrei) pick a short list of names you think make the most sense after the discussion has unfolded, then put them on a vote. If it ends in a tie, the two of you could exercise executive discretion in choosing the winner. The result could then be an official announcement that we could share in the community to further adoption.

> Destroy. I mean criticize.

Oh please, I think "destroy" reflects a healthy prevalence of openness to criticism in this community, let's not stop using it just because one or two newbies have announced some mild displeasure with it :P

On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
> I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple:
>
>     TypeTuple!(int, string) myExpressionTuple;
>     myExpressionTuple[0] = 42;
>     myExpressionTuple[1] = "foo";
>     // etc


One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.

On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
> One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.

They are one and the same.

On Thursday, 22 August 2013 at 13:46:12 UTC, Jakob Ovrum wrote:
> On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
>> One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.
>
> They are one and the same.

Almost, but not completely. They share implementation and much of observable behavior (and former can be used to initialize latter) but one is mutable run-time entity and other - compile-time (and thus, of course, constant). As they don't have proper representation in the type system, it makes them quite different.

On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
> On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
>> I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple:
>>
>>    TypeTuple!(int, string) myExpressionTuple;
>>    myExpressionTuple[0] = 42;
>>    myExpressionTuple[1] = "foo";
>>    // etc
>
>
> One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.

That is in the doc : "A Tuple whose elements consist entirely of types is called a TypeTuple. A Tuple whose elements consist entirely of expressions is called an ExpressionTuple. "

http://dlang.org/template.html#TemplateTupleParameter

On Thursday, 22 August 2013 at 13:53:45 UTC, Dicebot wrote:
> Almost, but not completely. They share implementation and much of observable behavior (and former can be used to initialize latter) but one is mutable run-time entity and other - compile-time (and thus, of course, constant). As they don't have proper representation in the type system, it makes them quite different.

I don't think it's correct or useful to label one as compile-time and the other as runtime. I think the mutability or immutability of the expression tuple is an obvious result of its lvalue-ish or rvalue-ish nature, respectively. As such - with the current semantics - I'm not sure it's important to be able to easily distinguish the two. I'd be happy to be convinced otherwise if you think it's important.

On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote:
> I don't think it's correct or useful to label one as compile-time and the other as runtime. I think the mutability or immutability of the expression tuple is an obvious result of its lvalue-ish or rvalue-ish nature, respectively. As such - with the current semantics - I'm not sure it's important to be able to easily distinguish the two. I'd be happy to be convinced otherwise if you think it's important.

I don't know either :) I am just trying to find some order in existing scheme. What frustrates me most in expression sequences being both runtime and compile-time is that compile-time still can act as if they are almost types:

alias a = TypeTuple!(1, 2); // ok
auto  b = TypeTuple!(1, 2); // also ok!

Isn't it the only entity in the whole language that can be used in type context (alias) and value context (initializer) at the same time?