On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg wrote:
> About `auto-expansion` problem: please add documentation that
> describes difference between `auto-expansion TypeTuple` and
> `TemplateArgumentList without auto-expansion`. I personally don't
> know any difference, probably because I didn't write too
> complicated meta code.

Added, does this help: http://wiki.dlang.org/DIP54#Auto-expansion_explained ?

> Also, can we keep bouth `auto-expansion TypeTuple` and
> `TemplateArgumentList whitout auto-expansion` (maybe, in a
> different module)?

Technically - yes. But I think it will cause more damage that help.

> Or, maybe, can we add documentation how to
> convert any  `auto-expansion TypeTuple` to the
> `TemplateArgumentList without auto-expansion`.

Like this?

alias Packed = TemplateArgumentList!(T); // assuming T is variadic template argument list, T...
alias Expanded = Packed.expand;

On 12/23/2013 04:02 AM, Dicebot wrote:
> On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
>> On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
>>> People who want auto-expanding template argument lists can still do
>>> this:
>>
>> It's not perfectly clear, but it looks to me that the DIP suggests
>> removing the auto-expanding property of template argument lists.
>
> No, it would have changed language feature which is deeply integrated
> with lot of stuff and thus is untouchable. This proposal is only about
> Phobos and documentation.

This misunderstanding arose because the name of the construct is misleading.

On Monday, 23 December 2013 at 03:45:07 UTC, Jakob Ovrum wrote:
>> We can't afford to add even more "tuple" types in library.
>
> One tuple and two compile-time lists - where the auto-expanding one covers the vast majority of use cases - doesn't sound at all bad.

I think this is the root cause of disagreement and everything else is just a consequence from it. I still remember my initial confusion when trying to figure out this part of the language - it wasn't really related to naming but more about trying to understand what intended use cases does each entity have. It is all natural once you start to casually use it but not before. If both types are present in the library in the same time we will need to explain why both are needed, what is the difference, when each is expected to be used and so on. It is a serious risk of cognitive overload considering one is already expected to get some grasp about native template argument lists and how those can be used. If there is only one type, it becomes considerably more simple - just use it and once you get familiar with it deep enough to need expansion behavior - `.expand` will be an expected discovery.

Also having both types at the same time will cause difficulties with template algorithms currently present in std.typetuple - having some defined in terms of raw argument list and others in terms of packed TemplateArgumentList is just another learning curve damage.

What is even more important - auto-expanding lists simply don't have any important value to preserve on their own as they are already present in form of raw template arguments and `.expand`. This was what made me change opinion on this topic back then.

On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
> This misunderstanding arose because the name of the construct is misleading.

Can explain this a bit? What makes one miss distinction between language term and library type? (Hint: latter is denoted by CamelCase ;))

On Monday, 23 December 2013 at 11:44:01 UTC, Dicebot wrote:
> On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg wrote:
>> About `auto-expansion` problem: please add documentation that
>> describes difference between `auto-expansion TypeTuple` and
>> `TemplateArgumentList without auto-expansion`. I personally don't
>> know any difference, probably because I didn't write too
>> complicated meta code.
>
> Added, does this help: http://wiki.dlang.org/DIP54#Auto-expansion_explained ?

Oh, I see. Thank you for the example. It really looks like `TemplateArgumentList without auto-expansion` is more generic solution.
Please, add similar example to the Phobos documentation (for example, to the `http://dlang.org/tuple`) when you will implement this DIP.

>
>> Also, can we keep bouth `auto-expansion TypeTuple` and
>> `TemplateArgumentList whitout auto-expansion` (maybe, in a
>> different module)?
>
> Technically - yes. But I think it will cause more damage that help.
>
>> Or, maybe, can we add documentation how to
>> convert any  `auto-expansion TypeTuple` to the
>> `TemplateArgumentList without auto-expansion`.
>
> Like this?
>
> alias Packed = TemplateArgumentList!(T); // assuming T is variadic template argument list, T...
> alias Expanded = Packed.expand;

Yes, exactly.
Can we add alias for `auto-expansion TypeTuple` and add link to the previous documentation like this:

alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;

It looks like it can fix all objections here.

Jakob Ovrum:

> One tuple and two compile-time lists - where the auto-expanding one covers the vast majority of use cases - doesn't sound at all bad.

Plus built-in syntax to unpack tuples in various situations.

Bye,
bearophile

On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
> Can we add alias for `auto-expansion TypeTuple` and add link to the previous documentation like this:
>
> alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
>
> It looks like it can fix all objections here.

What is this supposed to give over just using .expand directly? I have not seen a good rationale that justifies it among existing objections, probably have missed it.

On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
> On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
>> Can we add alias for `auto-expansion TypeTuple` and add link to the previous documentation like this:
>>
>> alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
>>
>> It looks like it can fix all objections here.
>
> What is this supposed to give over just using .expand directly? I have not seen a good rationale that justifies it among existing objections, probably have missed it.

As I understand, the main objection is that people want to see additional `auto-expansion TypeTuple` type. This alias is simple enough to explain that `.expand` and `ExpandedTemplateArgumentList` means the same. But I agree that it's not so critical to have this alias.

On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>

Full support. Never used tuple or TypeTuple since I don't understand what they are for, and their precise relationship to templated argument lists. Better names will help.
A code breakage with a compilation error is way nicer that a silent code breakage (as an example disallow the implicit conversion from static arrays to pointer broke way more code, but was safe and generally a good thing).

On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
> On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
>> Can we add alias for `auto-expansion TypeTuple` and add link to the previous documentation like this:
>>
>> alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
>>
>> It looks like it can fix all objections here.
>
> What is this supposed to give over just using .expand directly? I have not seen a good rationale that justifies it among existing objections, probably have missed it.

It allows doing a simple 's/TypeTuple/ExpandedTemplateArgumentList/'

Using "TemplateArgumentList!(T).expand" is a "much" more involved transition: It's not just a simple rename.

Personally, I'd prefer the name "TemplateArgumentList" be "PackedTemplateArgumentList". By doing this, the "duality" of:
* ExpandedTemplateArgumentList
* PackedTemplateArgumentList

Will mean there will be absolutly *no* ambiguity in which is being used and how, and keep surprises to an absolute low. It keeps things explicit, and doesn't force a "default" behavior on the programmer: The programmer makes the choice all the time.