Collections question

[Andrei Alexandrescu via Digitalmars-d]

On 11/30/2015 12:56 PM, bitwise wrote:
> On Saturday, 28 November 2015 at 13:39:35 UTC, Andrei Alexandrescu wrote:
>> On 11/28/15 1:59 AM, bitwise wrote:
>>>
>>> Classes/real-ref-types dont act as you're describing, so why should
>>> these fake struct wrapper ref things act this way? This will likely
>>> achieve the exact opposite of what you're aiming for, by making
>>> something that's supposed to act like a reference type have different
>>> behaviour from D's built in ref types.
>>
>> So what would work for you? -- Andrei
>
> Sorry if that response seemed a tad flippant, but I have to be
> honest...I am completely against this design...to put it mildly.
>
> I have my own containers to use, but on top of the fact that I would
> prefer something which is collaboratively maintained, I don't want to be
> forced to deal with, or support these "reference" containers, which will
> most likely happen if they get added to Phobos.
>
> I'm really not sure where to begin tearing this idea apart. The
> principal I have a problem with is much more fundamental than this one
> decision. In general, there is a lot in D that is very hackish.
>
> I understand that you don't want eager copying of containers, but when I
> way predictability, simplicity, clarity, and flexibility against that
> concern, there is no way I'm agreeing with you, when you can simply wrap
> a proper container in a RefCounted(T) or something. A class is a
> reference type, and a struct is a value type. If a user sees a struct,
> they should expect a value type which will copy on assign, and if they
> see a class, they should expect a reference. In D, the differentiation
> between value and reference types is clearly specified, and D users
> _should_ be, and should be expected to be, aware of it.
>
> If you really want reference containers, they should be implemented
> either as value-type structs, or classes that can work with
> RefCounted(T). Baking the reference count directly into the container is
> limiting, and buys nothing. I really don't see a problem with GC'ed
> classes if you really want reference types. It's going to be forever, if
> ever before you can actually turn off the GC when using Phobos. At
> least, if it's a class, you can use Scoped(T), or RefCounted(T) on
> it...assuming RefCounted(T) is fixed up to work with classes at some
> point, which seems like a better path then baking ref counting into a
> container implementation.
>
> I'm feeling a bit repetitive at this point, and wondering if I should
> have responded to this at all, and I'm sure you know exactly what I'm
> talking about, and that it's a matter of choice at this point, but there
> you have it.

Thanks, your response is appreciated! Let me make sure I understand. So, 
in your opinion:

* Value containers plus a way to wrap them with RefCounted is a better 
solution than containers with built-in reference semantics.

* The design supported by D most naturally is: classes have reference 
semantics and structs have value semantics.

* Reference semantics for containers seem to work best with GC. Pursuing 
reference containers with baked-in RC seems nonproductive.

This is all sensible. Here are a couple of follow-up questions and 
considerations:

* I couldn't integrate this with the rest of your post: "The principal I 
have a problem with is much more fundamental than this one decision. In 
general, there is a lot in D that is very hackish." Could you please 
elaborate?

* The one matter with the value/RefCounted approach is that RefCounted 
cannot be made @safe. One core design decision I made was to aim for 
safe containers. I do agree that if safety is off the table, your design 
would be a very good choice (probably the best I can think of, and I'd 
start an implementation using it).


Thanks,

Andrei