std.container and classes

[Jonathan M Davis]

On Saturday, December 17, 2011 22:57:46 Caligo wrote:
> On Tue, Dec 13, 2011 at 9:08 PM, Jonathan M Davis 
<jmdavisProg at gmx.com>wrote:
> > Is the plan for std.container still to have all of its containers be
> > final classes (classes so that they're reference types and final so
> > that their functions are inlinable)? Or has that changed? I believe
> > that Andrei said something recently about discussing reference counting
> > and containers with Walter.
> > 
> > The reason that I bring this up is that Array and SList are still
> > structs, and
> > the longer that they're structs, the more code that will break when they
> > get
> > changed to classes. Granted, some level of code breakage may occur when
> > we add
> > custom allocators to them, but since that would probably only affect the
> > constructor (and preferably wouldn't affect anything if you want to
> > simply create a container with the GC heap as you would now were Array
> > and SList classes), the breakage for that should be minimal.
> > 
> > Is there any reason for me to not just go and make Array and SList final
> > classes and create a pull request for it?
> > 
> > - Jonathan M Davis
> 
> What happens in cases where you need to extend functionality of those
> containers by inheritance?  With structs you'll have to rely on composition.

You have to rely on composition in either case. If std.container uses classes, 
they're going to be final. The reason is that if you don't do that, its 
functions are virtual and can't be inlined. For containers which get used all 
over the place and need to be as efficient as possible, that's not acceptable. 
And it's fairly rare to need to derive from a container class anyway. Yes, 
it's useful sometimes, but that occasional use case does not merit the cost to 
the general case.

So, _all_ extending of containers will require composition, regardless of 
whether we use structs or classes.

- Jonathan M Davis