On Monday, 23 December 2013 at 03:17:27 UTC, Dicebot wrote:
Hard? No. Complicated - yes, I see wrong assumptions being made all the time. But this is language failure and is not directly related to this DIP.
I don't think it's obvious that it's a language failure.
I don't say that. I say that it will allow to avoid introduction of _third_ tuple type into Phobos which would have makes things even harder to learn.
It wouldn't be the third tuple type, it would be the second type of list.
Algorithm that operates on variadic amount of template argument lists can't be expressed with TypeTuple behavior.
They would be amply supported by using the second type of list. Still, there are no examples of such algorithms presented by the DIP. Without substantial evidence, they are niche at best or virtually non-existent at worst (though I'm sure it's the former). In either case, I don't think they warrant conflation with auto-expanding lists.
Well, if you will actually find those threads, you will see that I was in favor of auto-expanding behavior ;) It was Andrei who has convinced me.
Then I apologize, and retract my comment.
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 we can conclude that auto-expanding lists cover the vast majority of cases on the basis that all of Phobos and virtually all other libraries use auto-expanding lists to great effect without interface contrivances.
My argument comes down to the fact that I think the issue of auto-expansion is orthogonal to the naming issue; yes, I acknowledge it would be beneficial to solve both at once, but such an integrated solution is predicated on the fact that auto-expansion is an issue in the first place, which I don't think the DIP addresses sufficiently.
I *do* think it does sufficiently address the fact that the current naming scheme is a problem.
