DIP54 : revamp of Phobos tuple types

[Dicebot]

On Friday, 14 March 2014 at 11:01:15 UTC, John Colvin wrote:
> On Friday, 14 March 2014 at 09:55:34 UTC, Jakob Ovrum wrote:
>> On Friday, 7 March 2014 at 19:06:27 UTC, Dicebot wrote:
>>> Have updated the DIP to include feedback from this thread : 
>>> http://wiki.dlang.org/DIP54
>>>
>>> It effectively means resorting back to both std.meta.pack and 
>>> std.meta.list as a compromise.
>>
>> LGTM.
>>
>>> Hope to start working on it soon. Ironically, getting a D job 
>>> has stripped me of almost all time spent on side D tasks so 
>>> progress is very slow, sorry :(
>>
>> Perhaps you can delegate some tasks to other members of the 
>> community. I vaguely remember other members working on similar 
>> modules to std.meta.*, too (John Colvin?).
>
> Yes, I am using an almost identical layout to what is proposed 
> in this DIP.
>
> The bulk of the work is done, but tests are thin on the ground. 
> I have a whole bunch of changes that haven't been commited and 
> pushed to github yet. I should be able to bring everything up 
> to date over the weekend.
> Also, I noticed I haven't attributed some work I stole from 
> other peoples pull requests, so I'll fix that too.

By the way, can you separate your work in 2 parts - one that 
exactly mirrors existing std.typetuple functionality and second 
one with any additions? We shouldn't process those under single 
review process.

> There are a few enhancements to the language that would make a 
> big difference, as well as some bugs that are holding me back.

Can you list those? (with a high priority for those that impact 
"base" proposal)

For me main issue is lack of symbol-based opSlice / opIndex but 
as I have already mentioned fixing it is a bit over my current 
DMD knowledge.

> In particular, if there was such a thing as "symbol opDispatch" 
> that provided an alias to the symbol used after the . instead 
> of a string, UFCS for templates would be workable without 
> horrible leaky abstractions.

I don't think it is a good feature, it probably can't even be 
done within existing language semantics. Probably your problem 
can be solved via other means?