DIP54 : revamp of Phobos tuple types

[John Colvin]

On Friday, 14 March 2014 at 13:32:34 UTC, Dicebot wrote:
> 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.
>

Sure.

>
>> 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)
>

I'll take a look over the weekend.

> 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?

It's very nice to be able to write like this:

enum integerStorageLength = 
TL.Map!isIntegral.Filter!isTrue.length;

(admittedly that example would easily done other ways)

It can already work completely seemlessly for templates internal 
to std.meta, or indeed for module-global public templates from 
anywhere. It's only for local/private/protected symbols from 
outside that a "symbol opDispatch" is needed.