On Mon, Dec 23, 2013 at 7:34 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> I'm waiting to see what others who use TypeTuples think of the DIP. E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure (most) of these guys use tuples a lot.

Much as I like non-expanding tuples, I've to admit most of the
standard uses of tuples (er, template argument lists) are easier if
they auto-expand/flatten.
I agree there are symbols that should be renamed to avoid confusion,
so I agree with the renaming part.

As for non-expanding, I tend to create my own (any template struct
will do), but std.typecons.Tuple is perfectly serviceable.
My main use is to create trees: lists are good, but there are
structures that need a bit more... oomph. For example:

auto myBox =
computer(
    processor(
        cores(4),
        speed(3500.Hz),
        Processor.i586
    ),
    disk(
        size(500.TiB)
    ),
    disk(
        size(750.TiB),
        speed(7200.rpm),
        Disk.SATA
    ),
    screen()
);

When everything above returns a new type, possibly holding other
types, and so on. The resulting type is one big tuple of tuples. I
think those could be a possible way to get an internal DSL in D, at
the same time statically checked by the compiler and easy to use for
the programmer.
So I need generic code to iterate on it, process it, modify it... But,
as I said in that case, I create my own structs.

24-Dec-2013 04:57, bearophile пишет:
> Andrei Alexandrescu:
>> It often does make code shorter.
>
> It also avoids the programmer to think about useless details, leaving
> more brain for more important things. Assigning the fields to variables
> like this:
>
> const uselessTmp = foo();
> immutable something = uselessTmp[0];
> immutable secondThing = uselessTmp[1];
> const theLast = uselessTmp[2];
>
> is as efficient as leaving that to the compiler.
>

Agreed. IMHO destructuring of structs, tuples and arrays is something we ought to have at some point.

Something not unlike ECMA Script:
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
http://wiki.ecmascript.org/doku.php?id=proposals:destructuring_assignment

> Bye,
> bearophile


-- 
Dmitry Olshansky

24-Dec-2013 09:00, Jakob Ovrum пишет:
> On Tuesday, 24 December 2013 at 04:48:57 UTC, Jakob Ovrum wrote:
>> [1] Assuming that the case for non-auto-expanding lists can be argued
>> sufficiently for inclusion in Phobos, which is yet to be seen. This
>> DIP doesn't seem to even try.
>
> Clarification: "Assuming that the case for non-auto-expanding lists can be
>> argued sufficiently for inclusion in Phobos, in the context of list
>> algorithms that take a variadic number of variadic lists as arguments."
>
> I feel that non-expanding lists only make sense in the context of these
> niche algorithms for the reasons explained in the parent post, and thus
> do not warrant conflation with auto-expanding lists.

As long as algorithms that operate say on 2 lists expect arguments to have '.expand' we'd be in a good shape just providing a `packList` or some such together with `list`.

It would even work out of the box with current user-defined pack types if they have .expand.

-- 
Dmitry Olshansky

On Tuesday, 24 December 2013 at 10:30:47 UTC, Dmitry Olshansky wrote:
> As long as algorithms that operate say on 2 lists expect arguments to have '.expand' we'd be in a good shape just providing a `packList` or some such together with `list`.

I think so too. Of course, it is predicated on the fact that such algorithms are added to Phobos. Note that when an algorithm always expects 2 lists we can use nested templates instead, which has some benefits.

The issue, of course, is that this proposal suggests having only `packList` and changing all list algorithms to expect packed lists, which I think (and have elaborated upon) is a nasty case of fighting the language for no benefit, but for serious code breakage and lots of extra code on lines that tend to be long already[1].

> It would even work out of the box with current user-defined pack types if they have .expand.

Right, std.typecons.Tuple happens to be one such type.

[1] It's not the case that we can simply search and replace `TypeTuple!(...)` => `TemplateArgumentList!(...).expand` and call it a day; consider code like:
---
auto fun(Ranges...)(Ranges ranges)
    if (!is(CommonType!(staticMap!(ElementType, Ranges)) == void)
{
    ...
}
---
If list algorithms are changed to receive packed list, the `Ranges` argument to `staticMap` must be changed to `TemplateArgumentList!Ranges`.

Winter holidays have distracted me a bit, back to this topic.

I have been thinking about concerns mentioned for a while, this is proposed update to DIP in question to address those. Hope that will be a more acceptable compromise to everyone.

1)
Timon has raised the point that exact match between in naming between built-in and library type will be confusing as they will actually differ in behavior (http://forum.dlang.org/post/l99mke$q1o$1@digitalmars.com). Andrei has proposed `TemplateArgumentPack` as an alternative (http://forum.dlang.org/post/l9b5cu$2rsj$2@digitalmars.com) which I do like a lot.

That will also imply naming of module `std.meta.pack` instead of `std.meta.list`

2)
Despite my initial desire to standardize API between library types it seems that breakage will be much more damaging than I have initially expected. Jakob example (http://forum.dlang.org/post/vkeqyorptcobufzmmhgm@forum.dlang.org) does not look _that_ bad but imagining is(typeof()) error suppression on top is pain.

I reconsider that proposal.

As an alternative, I propose signatures of existing templates as-is but augment them all with overloads taking single `Pack` (and make it requirement when introducing new ones). New multilist utilities added are expected to use `Pack`s (I am still convinced that using nested templates for that is ugly)

3)
Point about omitting expanding library type still remains. I am still looking for use case when those are really necessary (as a library type).

Does that look more acceptable? Jakob, Andrej?

On 12/29/13 3:09 AM, Dicebot wrote:
> 1)
> Timon has raised the point that exact match between in naming between
> built-in and library type will be confusing as they will actually differ
> in behavior (http://forum.dlang.org/post/l99mke$q1o$1@digitalmars.com).
> Andrei has proposed `TemplateArgumentPack` as an alternative
> (http://forum.dlang.org/post/l9b5cu$2rsj$2@digitalmars.com) which I do
> like a lot.
>
> That will also imply naming of module `std.meta.pack` instead of
> `std.meta.list`

I think a duo `TemplateArgumentList` (auto-expansion) and `TemplateArgumentPack` (no auto-expansion) in the same module is the ticket. It also makes for a wonderful opportunity to explain the distinction in the documentation and recommend idioms for each.

> As an alternative, I propose signatures of existing templates as-is but
> augment them all with overloads taking single `Pack` (and make it
> requirement when introducing new ones). New multilist utilities added
> are expected to use `Pack`s (I am still convinced that using nested
> templates for that is ugly)

To use your own argument: why add all those overloads instead of requiring the user to use .expand with a TemplateArgumentPack (or assuming we go with my suggestion above, just use a TemplateArgumentList in the first place)?

> 3)
> Point about omitting expanding library type still remains. I am still
> looking for use case when those are really necessary (as a library type).

See above. I think several people argued that there are plenty of places where automatic expansion is the desired behavior.


Andrei

On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
> On 12/29/13 3:09 AM, Dicebot wrote:
>> 1)
>> Timon has raised the point that exact match between in naming between
>> built-in and library type will be confusing as they will actually differ
>> in behavior (http://forum.dlang.org/post/l99mke$q1o$1@digitalmars.com).
>> Andrei has proposed `TemplateArgumentPack` as an alternative
>> (http://forum.dlang.org/post/l9b5cu$2rsj$2@digitalmars.com) which I do
>> like a lot.
>>
>> That will also imply naming of module `std.meta.pack` instead of
>> `std.meta.list`
>
> I think a duo `TemplateArgumentList` (auto-expansion) and `TemplateArgumentPack` (no auto-expansion) in the same module is the ticket. It also makes for a wonderful opportunity to explain the distinction in the documentation and recommend idioms for each.

This is the approach I have followed when trying to write std.meta, however I decided to split them in to two seperate modules. Then again, my module layout is a mess and I will probably rearrange considerably before submitting to the review queue.

The recommended idioms drop out very neatly: `TemplateArgumentList` is for genuine variadic template arguments (where possible), `TemplateArgumentPack` is for everything else. In particular, with a (nearly)full port of std.range and std.algorithm, TemplateArgumentPacks can be used as an analogue of arrays.

On Sunday, 29 December 2013 at 11:10:00 UTC, Dicebot wrote:
> Despite my initial desire to standardize API between library types it seems that breakage will be much more damaging than I have initially expected. Jakob example (http://forum.dlang.org/post/vkeqyorptcobufzmmhgm@forum.dlang.org) does not look _that_ bad but imagining is(typeof()) error suppression on top is pain.

Breakage that causes errors in secondary locations and cannot be automatically repaired (e.g. search & replace) is the worst kind of breakage, after silent failures, that I can think of.

> As an alternative, I propose signatures of existing templates as-is but augment them all with overloads taking single `Pack` (and make it requirement when introducing new ones).

Not a single of the existing algorithms need packed lists. Further, this DIP doesn't present a single algorithm that *does* need packed lists. It adds a huge maintenance cost and cognitive cost for no benefit.

> New multilist utilities added are expected to use `Pack`s (I am still convinced that using nested templates for that is ugly)

I don't consider "it's ugly" with no elaboration a valid argument.

> Point about omitting expanding library type still remains. I am still looking for use case when those are really necessary (as a library type).

As elaborated upon in an earlier post[1], I think auto-expansion is *the* use case for template argument lists, as a natural consequence of language features. That's what makes this DIP so absurd - you are asking everyone to type `.expand` literally everywhere such a list is actually applied. The only tangible rationale for this was that auto-expansion is hard to learn, which I think is not only unsubstantiated, but rather moot because I think *expansion* is what needs grokking, and there's no way around that because at the end of the line, expansion is the only use case of template argument lists.

By fixing the naming issue, we'd be making strides in easing teaching of list expansion, without making lists harder to use by sometimes requiring `.expand` and sometimes not, sometimes requiring `TemplateArgumentPack!Args` and sometimes just `Args`, and without breaking code in non-trivial ways.

[1] http://forum.dlang.org/post/glqrqbynhpeidktrbjca@forum.dlang.org

On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
> I think a duo `TemplateArgumentList` (auto-expansion) and `TemplateArgumentPack` (no auto-expansion) in the same module is the ticket. It also makes for a wonderful opportunity to explain the distinction in the documentation and recommend idioms for each.

I am concerned about cognitive load that explanations of all those concepts at once creates. Having minimal type set allows to descend deeper iteratively. It will also be hard to explain why this type is _needed_ in stdlib (at least for me, because I have no answer for that)

> To use your own argument: why add all those overloads instead of requiring the user to use .expand with a TemplateArgumentPack (or assuming we go with my suggestion above, just use a TemplateArgumentList in the first place)?

Signature consistency. If you will use different algorithms in same code snippet (some with single variadic argument, some with multiple) having some of arguments augmented with .expand and some not is rather ugly.

I don't have strong preference here though and will be fine without adding overloads.

>> 3)
>> Point about omitting expanding library type still remains. I am still
>> looking for use case when those are really necessary (as a library type).
>
> See above. I think several people argued that there are plenty of places where automatic expansion is the desired behavior.

Yep, but none of those featured auto-expanding _library_ type as part of desired behavior. May you point at specific example I have missed please?

On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
> I think a duo `TemplateArgumentList` (auto-expansion) and `TemplateArgumentPack` (no auto-expansion) in the same module is the ticket. It also makes for a wonderful opportunity to explain the distinction in the documentation and recommend idioms for each.

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 also think it should be shorter, because a) it's a fundamental, and thus very commonly used template, and b) code that manipulates lists are functional in nature which results in long lines that are also hard to split up because sometimes they are in template constraints or function template parameter lists etc.

I like the name `list`.