druntime, templates and traits

[Maxim Fomin]

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.