druntime, templates and traits
monarch_dodra
monarchdodra at gmail.com
Fri Sep 13 12:16:01 PDT 2013
On Friday, 13 September 2013 at 18:01:30 UTC, H. S. Teoh wrote:
> 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?
Oh. Right. I understood you backwards. In that case, it's not
nothrow simply because it hasn't been made that way yet. On topic:
https://github.com/D-Programming-Language/druntime/pull/553
- Me trying to make assumeSafeAppend nothrow, and learn how
druntime works.
>> 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
Hum. I wouldn't mind "starting" with reserve, and see from there
what the best thing to do for dup/idup is from there (including
just making it a free function in object ?)
An added plus about making it an actual UFCS in object.d, is that
we'll be able to (correctly) write it as "myArray.dup()".
It's not a property god damn it!
More information about the Digitalmars-d
mailing list