On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
> ...

Sorry, can you make a short summary about your position? You are against adding packed list to library or just against removing expanding one (from the library)?

On Sunday, 29 December 2013 at 15:45:59 UTC, Dicebot wrote:
> On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
>> ...
>
> Sorry, can you make a short summary about your position? You are against adding packed list to library or just against removing expanding one (from the library)?

Packed lists are a niche, which necessity isn't well argued by this DIP, so I suggest we postpone assessment of packed lists until their utility is proven. (Personally I suspect their utility will prove plenty worthy of Phobos)

Auto-expanding lists cover the vast majority of use cases, so we shouldn't conflate them with packed lists because this comes at various costs.

On 12/29/13 7:42 AM, Jakob Ovrum wrote:
> 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.

Fine.

> 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.

No. This is the wrong place to go for short names.

> I like the name `list`.

Define your own alias that way and let the long self-explanatory be.


Andrei

On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> No. This is the wrong place to go for short names.

It would be nice to hear more than "no" when I provided two very good reasons for why I think this is the right place to go for a short name.

>> I like the name `list`.
>
> Define your own alias that way and let the long self-explanatory be.

Consistency is king; the standard name will almost always trump any other name for readability. Defaults are important :)

On 12/29/13 8:14 AM, Jakob Ovrum wrote:
> On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu wrote:
>>> 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.
>>
>> No. This is the wrong place to go for short names.
>
> It would be nice to hear more than "no" when I provided two very good
> reasons for why I think this is the right place to go for a short name.

It's been discussed before - these are advanced notions that won't be used frequently and naively.

>>> I like the name `list`.
>>
>> Define your own alias that way and let the long self-explanatory be.
>
> Consistency is king; the standard name will almost always trump any
> other name for readability. Defaults are important :)

Yeah, on the other hand we don't want to go down in history as the language that named 'list' something that's emphatically not that.


Andrei

On Sunday, 29 December 2013 at 16:19:57 UTC, Andrei Alexandrescu wrote:
> It's been discussed before - these are advanced notions that won't be used frequently and naively.

I guess I'm biased by writing a lot of library code, where it's quite frequently used. I can imagine application code using it much less.

> Yeah, on the other hand we don't want to go down in history as the language that named 'list' something that's emphatically not that.

That's a good point.

29-Dec-2013 20:01, Andrei Alexandrescu пишет:
> On 12/29/13 7:42 AM, Jakob Ovrum wrote:
>> On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> No. This is the wrong place to go for short names.

And having to deal with all kinds of aliases people are _expected_ to create? Why not pick something accessible in the first place?



-- 
Dmitry Olshansky

Back to fighting :)

On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
> 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.

This is why I have considered this a serious objection and changed my mind on that topic. Or have I still missed some possible breakage of that kind&

>> 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.

Of course because we have damn nothing in our template algorithm set. Those are just basics. If stuff goes as planned std.meta.* will have template alternatives of almost all stuff from std.range and std.algorithm. Any function from there that takes pair of ranges or range of ranges will be subject to this decision. Should I list them all?

You words about "huge maintenance cost" are pretty much as subjective and unproved as my "it is ugly" statement. If anything, packed lists result in easier maintenance as they make list passing more hygienic and in line with passing of any other aliases and flattening/merging of lists explicit and obvious. There has been one guy even in this thread who was surprised by current behavior.

And built-in variadic templates will remain anyway, so question is not "what merit auto-expanding list does have" but "what merit auto-expanding list does have as an extra library type".

>> 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.

"It is completely out of line with existing function signatures for non-template algorithms that it mirrors"

>> 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,

I'll copy list from there:

"Use for declaring an expression list from a type list" - not common at all and pretty much never used by anyone but very experienced library writers (it is rather arcane thing on its own)

"Use for initalizing other expressions lists with an expression
list" - should require expansion anyway because it is how std.typecons.Tuple works

"Use in static foreach" - works with alias this

"Use in special expressions that operate on types, such as `is`,
`typeof` and `typeid`" - any code that does on expanded lists right now is completely broken and must be re-written according to existing spec. Exanded argument list is not a valid type for any of those entities (despite it is magically accepted). Indexing single element works with "alias this".

"Use as a public alias in a library interface, leaving the
specifics of application to the user" - irrelevant to expansion as you mention on your own

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. I will work on DMD PR if this is going to be accepted as "the way".

> 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.

Yep, this is an attempt to somewhat compensate bad language decision by more hygienic library solution. Your rationale is based on assumption that language feature is OK an anything else should be based on it. But it is not OK in general, only for very few library writers.

My key point is that common and basic use cases that are likely to appear in casual code should take priority over needs of library writers as latter are ready to deal with extra complexity pretty much by definition. I am personally ready to do it despite it will cause problems/inconvenience for my own code. simply because it is bigger than that. Your arguments about use cases are very biased towards that librar'ish usage. We don't have any hard stats here so someone else needs to make the judgement but I think you are mistaken in how widely applicable it is.

> expansion is the only use case of template argument lists.

You keep repeating it and have not shown strong evidences for it so far. Core use cases for template arguments in common user code is indexing and iteration which can "just work" for packs too.

> 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.

If we won't address this question at the same time it will pop up again once std.meta.* pull request will start to appear and deferring decision to that point will just force users to adjust same code twice. That does not sound good.

On Sunday, 29 December 2013 at 19:02:57 UTC, Dmitry Olshansky wrote:
> And having to deal with all kinds of aliases people are _expected_ to create? Why not pick something accessible in the first place?

Because no good short name has ever been proposed so far. I'd strongly discourage creating public aliases for that in exposed code (as opposed to module/package internals) for this very reason.

On 12/29/2013 10:41 PM, Dicebot wrote:
>...
> "Use in static foreach" - works with alias this
>
> "Use in special expressions that operate on types, such as `is`,
> `typeof` and `typeid`" - any code that does on expanded lists right now
> is completely broken and must be re-written according to existing spec.
> Exanded argument list is not a valid type for any of those entities
> (despite it is magically accepted). Indexing single element works with
> "alias this".
> ...

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.)

> ...
>
> 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? I find the fact that alias this is required for implementation of either Tuple or Pack to be an annoying language limitation.

> I will work on DMD PR if this is going to be accepted as "the way".

I think this will require another DIP.