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

Personally I would be happy to help with the task of rewriting dlang.org/tuple and other documentation. Since the name of the page itself is problematic, I suggest we introduce a new page with the migrated and rewritten tuple.dd information (named what, though? I think it should cover both lists and packs), then leaving tuple.dd as a small stub that succinctly explains the terminology change as well as linking to the new page, std.typecons.Tuple/std.tuple and probably to DIP54, too.

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.

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

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.

On Friday, 14 March 2014 at 09:55:34 UTC, Jakob Ovrum wrote:
>> 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?).
>
> Personally I would be happy to help with the task of rewriting dlang.org/tuple and other documentation. Since the name of the page itself is problematic, I suggest we introduce a new page with the migrated and rewritten tuple.dd information (named what, though? I think it should cover both lists and packs), then leaving tuple.dd as a small stub that succinctly explains the terminology change as well as linking to the new page, std.typecons.Tuple/std.tuple and probably to DIP54, too.

Code itself is not a big problem (thanks to John work), it is documentation that bothers me. Both terrible with writing docs and have only basic knowledge of DDOC. If someone can help with it, it will definitely speed up things.

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?

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.