DIP54 : revamp of Phobos tuple types

Jakob Ovrum jakobovrum at gmail.com
Sun Dec 22 19:45:02 PST 2013


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.


More information about the Digitalmars-d mailing list