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