D Ranges

[monarch_dodra]

On Sunday, 15 September 2013 at 12:17:34 UTC, Dmitry Olshansky 
wrote:
> 15-Sep-2013 12:39, monarch_dodra пишет:
>> On Saturday, 14 September 2013 at 06:18:02 UTC, Jonathan M 
>> Davis wrote:
>> I have a few issues with ref counted.
>>
>> First, if you *ever* place one in an array or an AA, then you 
>> will leak.
>> It is NOT designed for simply incorporating reference, but for
>> deterministic finalization.
>
> Another problem with built-in AAs...
>
>>
>> Second, it has an elaborate postblit and opAssign. This is not 
>> a big
>> issue in itself, but their sole existence does cause dmd to 
>> generate
>> code that is sub-optimal. It also means it can't take the 
>> "optimal"
>> route in a lot of algorithms (array has to emplace each element
>> individually, for example).
>
> Seriously we could do a better job then that.. For instance 
> blit the whole data, then call postblits on that range. 
> Exception safety would be trickier to achieve. Even better one 
> day I now expect compiler to be able to know that e.g. 
> RefCounted is registered as ARC-capable type then the compiler 
> should elide call to ref-counting.

Well, if a struct has no elaborate opAssign, then "=" *is* 
blit+postblit. And it doesn't get much more efficient than that.

If not, you have to pull out the memcpy, and things just go 
downhill from there.

>> Finally, a RefCounted will implicitly cast to its payload. I 
>> think this
>> is *horrible*. Before you know it, the Payload will have 
>> "jettisoned"
>> its wrapper, and you'll be operating on your value-type 
>> payload "raw".
>> For example:
>> void foo(T t);
>> RefCounted!T myRecCounted;
>> foo(myRefCounted); //Passes. Oops!
>
> Well it does a copy. Which is IMO perfectly fine.
> If you want to prevent that (at least in theory) you should 
> simply mark postblit of T as disabled.

It depends how you look at it. If the original intent was to have 
a type with reference semantics, because your value type was so 
damn big (eg, PRNG), then that would *not* be OK (and the 
original point I was making that RefCounted is a bad contender 
for "just" reference semantics).

If you are *trully* using it for deterministic finalization, then 
yeah, it's OK.