Transforming a range back to the original type?

[Jonathan M Davis]

On Friday, May 04, 2012 13:38:24 Steven Schveighoffer wrote:
> On Fri, 04 May 2012 13:09:06 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Friday, May 04, 2012 11:47:31 Steven Schveighoffer wrote:
> >> Yes, a struct can do reference semantics, but it makes little sense to
> >> fight the type system and shoehorn it into reference semantics, when
> >> classes are reference types by default.
> > 
> > A struct makes a lot more sense than a class when you need deterministic
> > destruction. IIRC, the last time that it was discussed, it was decided
> > that
> > we'd go with structs rather than classes, because it would work better
> > with
> > custom allocators, but it was a rather involved discussion, and I don't
> > remember all of the details.
> 
> Allocation and destruction are orthogonal to the problem. For example, in
> working on the new std.io, I've had to make RefCounted!(class) work, All
> I do is allocate the class data into the C heap.

It's not orthogonal if you want the allocation to be internal to the type and 
not have to worry about wrapping the container in a struct to actually get it 
to deallocate properly. For instance, you can allocate a class with malloc, 
but without a wrapper, you're going to have to keep track of the fact that it 
was allocated with malloc and make sure that you destroy it and free it. But 
if the container is a struct, then all of that can be internal, because the 
struct itself is on the stack rather than the heap. I don't see how you could 
use a custom allocator with a class and not have a wrapper, which means that 
using a custom allocator would affect the API of anything using containers that 
used them.

As I understand it, Andrei intends for the custom allocators to be dynamic, 
which means that the type of the container will be the same regardless of the 
allocator used. And if that's the case, I don't see how you can safely use 
classes as containers without always wrapping them in structs. And if you're 
going to do that, why whould you make them classes in the first place?

> The issue is, do you want pass by reference, or pass by value. My opinion
> is that it should always be pass by reference for container types. And
> classes make that *so* much easier.
> 
> With structs, you have to jump through hoops to get them to properly be
> reference types.

Yes. std.container's container types will most definitely be reference types, 
and yes, in general, that means that using classes would be better, but custom 
allocators throw a major wrench in that, because you need to control where the 
class is (which doesn't work very well without a wrapper, since without one 
you have to worry about freeing it manually), and many custom allocators need 
deterministic destruction, which classes don't provide.

I believe that this was the most recent discussion on the issue:

http://forum.dlang.org/post/mailman.1543.1323832143.24802.digitalmars-
d at puremagic.com

We'll have to see what Andrei actually proposes though, since he's been 
working on the custom allocators, and I don't know what has and hasn't changed 
as he's been working on them.

- Jonathan M Davis