druntime, templates and traits
monarch_dodra
monarchdodra at gmail.com
Fri Sep 13 03:26:33 PDT 2013
One of the "issues" of druntime is that is that almost everything
in it is resolved at runtime. This is good because it avoids
bloat. However, it also means we run into 2 regular issues:
1. Performance (small issue). A lot of code that should be
otherwise fast is slower than it could be, since druntime will
check, at runtime, if postblit is needed, if destruction should
be done. For example, if you "dup" a string by hand, you can do
it 50% faster than what druntime does.
2. Inference. This is an odd one. Currently, the function that
operate on arrays (reserve, dup, length) etc... may or may not be
@safe or pure. Or nothrow. The problem is that we really can't do
anything about it. duping a string is obviously nothrow, but if
you dup something with a postblit, then it might not be (nor
safe).
These issues kind of keep popping up in phobos, and we will have
to address them sooner or later. The current state of affairs is
a kind of status quo of "its wrong, inconsistent, but maybe OK
most of the time".
For example, "dup" is not nothrow, yet it is safe and pure.
Reserve is nothrow, yet assumeSafeAppend is not. Reserve may
actually call postblit, but not assumeSafeAppend.
========
The solution (I think) would be to partially templatize
d-runtime. We can keep most of what is in rt/lifetime.d, but
statically split it into smaller chunks, which could be piloted
with more accuracy via a templated "manager".
For now, if we could make a change as simple as "no postblit =>
safe pure nothrow, and fast guaranteed"/"postblit => not safe,
not pure, may throw", then it would already be a big win (IMO).
========
I had started toying around with this, and the main and immediate
challenge I ran into is the integration of templates. The 2
issues are:
1. All templates must be in object.d, or the compiler won't see
it.
2. A simple (and needed) trait like "hasElaborateCopyConstructor"
requires a good third of both "typetuple.d" and "traits.d".
"functionAttributes" is pretty simple though (I think).
So the two challenges are:
1. If we integrate a large amount of template code, where would
it go?
2. How will we deal with not having massive code duplication?
========
I'm mostly looking to start a discussion on this, and for
guidance, ideas, on where to start.
More information about the Digitalmars-d
mailing list