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/vkeqyorptcobufzmm...@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/glqrqbynhpeidktrb...@forum.dlang.org
