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.
