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
