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.
>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.
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...
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.
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.
