On Friday, 13 September 2013 at 10:26:35 UTC, monarch_dodra wrote:
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.
Yes, this is pitfall of D design.
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).
Yes, this is pitfall of D design.
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".
They are systematically popping up because of systematical
language features (D is statically typed language with little
runtime supported).
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".
It depends on how do you want to templatize it. Due to separate
compilation model it is impossible to know beforehand (when you
provide phobos library together with druntime) which types will
be used.
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).
Yes, this is pitfall of D design.
I'm mostly looking to start a discussion on this, and for
guidance, ideas, on where to start.
I doubt that the problems you raised are solvable in general case
with current runtime capabilities. While it still may be possible
to tackle some of them, D design (separate compilation model,
type system, templates, how pure, @safe, nothrow are defined)
would prevent you from fixing these problems.
