druntime, templates and traits

[H. S. Teoh]

On Fri, Sep 13, 2013 at 07:47:32PM +0200, monarch_dodra wrote:
> On Friday, 13 September 2013 at 17:02:24 UTC, H. S. Teoh wrote:
> >>>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.
> >
> >Why is assumeSafeAppend not nothrow? If it were up to me, I'd say
> >that if for whatever reason safe append can't be done (i.e. the
> >assumption is invalid) and we detect it, we should assert(0), since
> >the code is obviously not prepared to deal with this case by virtue
> >of calling assumeSafeAppend in the first place. Throwing an Exception
> >makes no sense in this case -- it's not something you can handle.
> 
> Well, by your own conclusion, it doesn't throw :D
> 
> It either just works, or it errors out. No exceptions.

Right, so how come assumeSafeAppend isn't marked nothrow?


> >>>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.
> >
> >public import is your friend. :)
> 
> What I'm getting so far from this conversation, is we should move
> select "foundation blocks" of typetuple/traits from phobos, into
> druntime. the phobos libraries would then publicly import their
> druntime counterparts.

Either that, or factor std.traits in terms of a small number of
fundamental primitives, and move those primitives into druntime.


> Then object.d would import "core/traits.d" and "core/typetuple.d"
> (or whatever).
> 
> Why "public" import btw? Wouldn't that expose the functions in
> traits/typetuple to *all* D code? That seems like a bad idea...

This was in response to your question about why stuff must be in
object.d(i) otherwise it won't be seen. If it's only needed internally,
then a public import is not necessary, but if you want stuff to be
imported by default into all programs, but don't want to bloat
object.di, then public import is the solution.

I've thought before, about splitting up object_.d into more manageable
chunks. Public imports would allow us to do this in a transparent,
backwards-compatible way.


> One of the problems though is that we'd want to try to keep those
> "core/traits" libraries as light as possible, since they'd be pretty
> much imported 99% of the time.

Yes, that's why I said above that we should distill the stuff we need
from std.traits into their barest essentials, and put those in druntime.
Then std.traits itself can add more user conveniences around these
primitives.


> Another issue to solve is that the above would work well for say,
> "reserve". However, "dup" (afaik) is hardwired by the compiler to
> call the druntime function "_adDupT". SO we'd have to change that if
> we even *hope* for it to infer anything.

Oh joy, more compiler magic. Let me know when you figure out how to
extricate it from the compiler, since it will probably be useful in
extricating AA's from the compiler as well. ;)

OTOH, another approach, since the compiler already hardcodes this stuff,
is to make the *compiler* infer attributes for .dup. That might actually
be easier than trying to move compiler-hardcoded stuff into druntime.
(The downside is that you'll have to work with C++... :-P)


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney