On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
> I think we should use this chance to rectify the capitalization of the name. As the result is not exclusively a list of types, current conventions state that the name should be lowerCamelCase.

I believe you got this one the wrong way around: Unless it is exclusively a list of values, the name should be camel cased. It is staticMap t a misnomer in that regard.

David

On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
> I think we should use this chance to rectify the capitalization of the name. As the result is not exclusively a list of types, current conventions state that the name should be lowerCamelCase.

I believe you got this one the wrong way around: Unless it is
exclusively a list of values, the name should be camel cased. It
is staticMap that is the misnomer in this regard.

David

On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
> What would be an example of code that you consider to be broken?
> (TemplateArgumentList!(int, double) is a valid type and TemplateArgumentList!(1, 2.0) is a value of that type.)

Stuff that relies that, for example, that `is(TypeTuple!(int, double) == typeof(TypeTuple!(42, 2.0)))`. There is no place in specification that defines / guarantees it or even define tuple as a valid type entity (or, to be precise, I have been looking for one and failed to find the mention). It behaves as if one is the instance of the other but is more of coincidence than intended rule.

I also remember Andrei mentioning in one of tuple threads that this relation is not supposed to be valid in general but it is very hard to find exact comment right now. Andrei can you please either confirm this or call me wrong? :)

>> Only thing I have difficulties with right now is defining static opSlice
>> for Pack so that it may return another Pack instead of raw list. But
>> that looks like compiler defect and should work as far as I read the
>> spec.
>
> This problem is also present in std.typecons.Tuple. Where does the spec claim that static opSlice can work for this use case?

It is in line with general rule of opXXX for structs working as syntax rewrite. Spec needs to claim it is not legal in that regard, not other way around ;) But for this to be helpful it needs to turn indexes into template arguments and this will be enhancement request for sure.

> I find the fact that alias this is required for implementation of either Tuple or Pack to be an annoying language limitation.

Me too. Maybe it should be addressed in general by defining template-argument opXXX - than it is subject of own DIP indeed. It is not critical for this DIP implementation so I did not think about it in details but it can make implementation much more hygienic.

On Monday, 30 December 2013 at 01:36:48 UTC, David Nadlinger wrote:
> On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
>> I think we should use this chance to rectify the capitalization of the name. As the result is not exclusively a list of types, current conventions state that the name should be lowerCamelCase.
>
> I believe you got this one the wrong way around: Unless it is exclusively a list of values, the name should be camel cased. It is staticMap t a misnomer in that regard.
>
> David

Do we actually have guidelines about casing in context of aliased content? I had impression that it is symbol on its own that matters and thus TemplateArgumentPack needs to be CamelCased simply because it is a type/template, whatever it aliases.

On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
> Do we actually have guidelines about casing in context of aliased content? I had impression that it is symbol on its own that matters and thus TemplateArgumentPack needs to be CamelCased simply because it is a type/template, whatever it aliases.

Then, all template functions would have to be camel-cased. See https://github.com/D-Programming-Language/phobos/pull/690 for a bikeshedding discussion about a related issue (expand the first "andralex commented on an outdated diff" comment stream – by the way, I still don't agree :P).

David

On Monday, 30 December 2013 at 03:19:36 UTC, David Nadlinger wrote:
> On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
>> Do we actually have guidelines about casing in context of aliased content? I had impression that it is symbol on its own that matters and thus TemplateArgumentPack needs to be CamelCased simply because it is a type/template, whatever it aliases.
>
> Then, all template functions would have to be camel-cased. See https://github.com/D-Programming-Language/phobos/pull/690 for a bikeshedding discussion about a related issue (expand the first "andralex commented on an outdated diff" comment stream – by the way, I still don't agree :P).
>
> David

Thanks for educating, good to know this rule :)

On 12/30/2013 03:58 AM, Dicebot wrote:
> On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
>> What would be an example of code that you consider to be broken?
>> (TemplateArgumentList!(int, double) is a valid type and
>> TemplateArgumentList!(1, 2.0) is a value of that type.)
>
> Stuff that relies that, for example, that `is(TypeTuple!(int, double) ==
> typeof(TypeTuple!(42, 2.0)))`. There is no place in specification that
> defines / guarantees it or even define tuple as a valid type entity (or,
> to be precise, I have been looking for one and failed to find the
> mention).

The spec is poor here, but it _still_ implies that the type of an 'expression tuple' is the corresponding 'type tuple'.

http://dlang.org/tuple.html

In any case, if something is to be fixed here it is the spec. It seems not formal enough if there can be any doubt that this is not intended behaviour. (Many language features are specified by example rather than by general rules.)

> It behaves as if one is the instance of the other but is more
> of coincidence than intended rule.
> ...

I'm sorry, but this is nonsense. The list of type / type of list confusion is not a rule that gets accidentally implemented in a compiler.

> I also remember Andrei mentioning in one of tuple threads that this
> relation is not supposed to be valid in general

Unlikely. Andrei is considered a D expert.

> but it is very hard to
> find exact comment right now. Andrei can you please either confirm this
> or call me wrong? :)
>
>>> Only thing I have difficulties with right now is defining static opSlice
>>> for Pack so that it may return another Pack instead of raw list. But
>>> that looks like compiler defect and should work as far as I read the
>>> spec.
>>
>> This problem is also present in std.typecons.Tuple. Where does the
>> spec claim that static opSlice can work for this use case?
>
> It is in line with general rule of opXXX for structs working as syntax
> rewrite.

No, it is not.

> Spec needs to claim it is not legal in that regard, not other
> way around ;)

???

> But for this to be helpful it needs to turn indexes into
> template arguments and this will be enhancement request for sure.
> ...

This.

>> I find the fact that alias this is required for implementation of
>> either Tuple or Pack to be an annoying language limitation.
>
> Me too. Maybe it should be addressed in general by defining
> template-argument opXXX - than it is subject of own DIP indeed. It is
> not critical for this DIP implementation so I did not think about it in
> details but it can make implementation much more hygienic.

It's critical if you want to support the real opSlice.

On 12/29/13 6:58 PM, Dicebot wrote:
> On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
>> What would be an example of code that you consider to be broken?
>> (TemplateArgumentList!(int, double) is a valid type and
>> TemplateArgumentList!(1, 2.0) is a value of that type.)
>
> Stuff that relies that, for example, that `is(TypeTuple!(int, double) ==
> typeof(TypeTuple!(42, 2.0)))`. There is no place in specification that
> defines / guarantees it or even define tuple as a valid type entity (or,
> to be precise, I have been looking for one and failed to find the
> mention). It behaves as if one is the instance of the other but is more
> of coincidence than intended rule.
>
> I also remember Andrei mentioning in one of tuple threads that this
> relation is not supposed to be valid in general but it is very hard to
> find exact comment right now. Andrei can you please either confirm this
> or call me wrong? :)

I don't understand the question. I think there's no particular relation between TemplateArgument{List,Pack}!(int, double) and TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the other is a list of two values, and yah, if you map typeof over the arguments in the latter it so happens you get the types in the first.

Template arguments lists are what they are - entities that can be passed to templates. Aliasing them is sensible but creating values thereof does not make sense.

Tuples are a different beast altogether. It would be nice to be able to extract their support types as a TemplateArgument{List,Pack} but that's about it.

One more word about providing TemplateArgument{List,Pack} vs. only one of them. Our users fall into categories such as:

0. Language lawyers who've studied the fine distinctions and are able to use either abstraction and define what they need if missing.

1. Experts who have an understanding of what they need and expect, and may or may not be surprised by whichever behavior we choose.

2. Users who have only a vague idea what the power is, and would have a difficult time using self-expansion when not needed or vice versa.

3. Users who don't know the first thing about the entire notion of grouping template arguments together.

I think we'd harm one or more categories of these users if we choose for them. We can't win. Conversely, we'd inform and please them all if we attacked the matter head on with a combination of TemplateArgument{List,Pack} and their afferent documentation.


Andrei

On Monday, 30 December 2013 at 03:44:49 UTC, Andrei Alexandrescu wrote:
> I don't understand the question. I think there's no particular relation between TemplateArgument{List,Pack}!(int, double) and TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the other is a list of two values, and yah, if you map typeof over the arguments in the latter it so happens you get the types in the first.

See example in that post. Right now you can apply typeof to template argument list despite it not being a first class type and get list of types of its elements. It also only place in language where it allows to apply typeof on type:

is(typeof(TypeTuple!(42, int)) == TypeTuple!(int, int))

It gets worse when you consider so called expression lists:

TypeTuple!(int, double) vals;

This looks like instance of type list but it is in fact works (afaik) effectively as:

int _tmp1;
int _tmp2;

alias vals = TypeTuple!(_tmp1, _tmp2);

It is yet another special case that makes template argument list act as first class type despite not being one.

As you may have notice confusion is so high that Timon did not even believe me remembering your quote about no particular relation between those two :)

> One more word about providing TemplateArgument{List,Pack} vs. only one of them. Our users fall into categories such as:
>
> 0. Language lawyers who've studied the fine distinctions and are able to use either abstraction and define what they need if missing.
>
> 1. Experts who have an understanding of what they need and expect, and may or may not be surprised by whichever behavior we choose.
>
> 2. Users who have only a vague idea what the power is, and would have a difficult time using self-expansion when not needed or vice versa.
>
> 3. Users who don't know the first thing about the entire notion of grouping template arguments together.
>
> I think we'd harm one or more categories of these users if we choose for them. We can't win. Conversely, we'd inform and please them all if we attacked the matter head on with a combination of TemplateArgument{List,Pack} and their afferent documentation.

If it is you judgement, let it be so. I prefer to start working on implementation whatever it is as opposed to endless discussion. What is your opinion about defining general guideline to use packs over nested templates for multi-list algorithms (another disagreement between me and Jakob)?

On 12/30/2013 04:44 AM, Andrei Alexandrescu wrote:
>
> I don't understand the question. I think there's no particular relation
> between TemplateArgument{List,Pack}!(int, double) and
> TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the
> other is a list of two values, and yah, if you map typeof over the
> arguments in the latter it so happens you get the types in the first.
>
> Template arguments lists are what they are - entities that can be passed
> to templates. Aliasing them is sensible but creating values thereof does
> not make sense.

You are doing it in the implementation of std.typecons.Tuple, and on every variadic function template call. How does it not make sense?