druntime, templates and traits
monarch_dodra
monarchdodra at gmail.com
Fri Sep 13 10:47:32 PDT 2013
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.
More information about the Digitalmars-d
mailing list