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?
