D Ranges

[Dmitry Olshansky]

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.

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


> The workaround would be to either require explicit "get" to go from ref
> counted to payload (breaking existing code), or to entirelly wrap the
> RefCounted as a member inside the struct (requires boilerplate code).

There is no need to prevent that in general case. Only RAII kind of 
things implemented with RefCounted would have problem copying-out the 
payload but these should have post-blit disabled for their "value" and 
consequently would not compile.

> --------
>
> Overall, if I need a reference semantic struct, I find it much simpler
> for it to just hold a GC pointer to a payload.

Ehm.. Isn't finalized class is just that? Plus bit of overhead for monitor.

> Though to be honest, as H.S. Teoh, I seriously wonder why I even bother,
> when I could just use a final class. With proper "private constructors +
> non-member "make" function", you can make your choice outright
> transparent to the final user too, meaning you can "fast prototype" with
> classes, and later change to structs if you think it is worth it.

This is true. And in fact I would encourage every D programmer to never 
expose constructors and always provide factory functions. These days 
constructors are constrained by a set of arcane limitations thusly suck 
beyond measure in every way possible. But you need them to say 
initialize immutable members, hence _use_ - but don't _expose_ them.

-- 
Dmitry Olshansky