DIP54 : revamp of Phobos tuple types

[Dicebot]

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.