Developing a plan for D2.0: Getting everything on the table

[Bill Baxter]

On Mon, Jul 27, 2009 at 10:01 AM, Bill Baxter<wbaxter at gmail.com> wrote:
> On Mon, Jul 27, 2009 at 9:54 AM, Bill Baxter<wbaxter at gmail.com> wrote:
>> On Mon, Jul 27, 2009 at 7:48 AM, Andrei
>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>> Leandro Lucarella wrote:
>>>>
>>>> Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
>>>>>>
>>>>>> For example, should the author of a container library prefer classes or
>>>>>> structs?
>>>>>
>>>>> I've been struggling with this forever. I don't know. I don't even know
>>>>> whether reference or value semantics are best for containers. I don't
>>>>> know whether abstract container interfaces and container-independent
>>>>> code are a net win; experience with STL seems to say "don't" and
>>>>> experience with Java seems to say "ho-hum".
>>>>
>>>> About values vs. reference semantics, I think reference is the best.
>>>> Containers usually are big, and you don't want to copy them arround.
>>>> I find myself using lots of references to pass containers arround in C++
>>>> and almost never use the copy() method of Python containers, so based on
>>>> *my* experience, I'd say that reference as the default is the best
>>>> approach.
>>>
>>> Sounds convincing.
>>
>> That's exactly right except for the times when it isn't and what you
>> want is value semantics.
>>
>> I've just finished recently refactoring some C++ code that wasn't
>> designed with copying in mind.  Changing all the "float* data; int
>> data_length;" members into std::vectors did the trick.  The data they
>> contained wasn't particularly large, and there was no real need to
>> introduce the complexity that sharing it between copied instances
>> would have created.
>
> So if I didn't make it clear -- my opinion is that whether containers
> should be by value or by ref depends on the circumstances and that
> choice should be left to the programmer.
>
> Thus the question becomes what's the easiest way to provide both?
> Three options I see:
>
> 1) Write ref classes and wrap them in structs
> 2) Write value structs and wrap them in classes
> 3) Write template mixins and mix them into both struct and class shells.
>
> I think given the existence of "alias this" for structs, 1 is actually
> the best-supported paradigm.
> I think with that you should be able to value-ize a by-ref container
> class just by writing a post-blitter to copy the contents.

Doh!  I didn't realize classes could "alias this" too!
So that would put 1 and 2 on equal footing in that regard.

But maybe one argument in favor of structs is that it is easier to
take value semantics and turn it into ref semantics.  You just need to
take a pointer.

So this:

class RefContainer
{
     alias this valContainer_;
     this() { valContainer = new ValueContainer; }
private:
     ValueContainer *valContainer;
}

gets you a basic working ref container out of a value container.  To
this you will probably want to add copy or clone type functionality.

In constrast:

struct ValueContainer
{
     alias this refContainer_;
     this() { refContainer = new RefContainer; }
     // must have add post-blit to get value semantics
private:
     RefContainer refContainer;
}

The requirement to add the post-blit is a little annoying.  If a
ValueContainer is made fundamental and it is built initially out of
components with value semantics, then no explicit post-blit will be
necessary.  However if you go the other way and start with a
RefContainer then a post-blit will be necessary when you implement the
ValueContainer based on it.   So to me it seems a little better to go
with the ValueContainer as the base implementation.

--bb