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