Andrei Alexandrescu Wrote: > BLS wrote: > > Question is, how this fits into a collection/container package. > > > > ..So frankly, I don't worry about naming conventions. I am more > > concerned about ranges within a let's say dynamic d e queue. > > Lock free ADTs are a final proof of product , no ? > > > > Maybe I miss something. > > But fact is : D2 (Phobos) still don't have (not even in it's brand new > > incarnation ) support for simple humpty dumpty collections. So Proof of > > product is where ? > > You're not missing anything, except for perhaps a little patience :o). > > There is vivid discussion about container support in D2. I was actually > thinking of posting a RFC sooner or later here. > > It is very exciting to realize that with minimal (and actually > simplifying) changes to the language we can offer the option of > garbage-collected vs. reference counted vs. "unsafe" semi-automatically > managed memory. Moreover, I realized that the global allocation model > only affects the built-in literal types such as T[] and T[U], but still > allows using the other models as library types. > > It has become increasingly clear we'll need to support arrays in > addition to slices. One big question mark for me is, should we define > for arrays (and associative arrays and containers in general) value > semantics, reference counted value semantics, or reference semantics? It > is not clear to me yet what the best option is. Think of arrays as an > archetypal example. > > 1. Value semantics (arrays are like int) > > + Simple to reason about > + No long-distance sharing of state > + Familiar to refugees coming from C++ with STL > - Unfamiliar to Java/C# refugees > + Relatively simple to implement > + Good behavior as members inside structs and classes > - Bad behavior as function parameters: if you forget to pass by > reference, performance will be harmed > > 2. Value semantics with reference counting > > +- All tradeoffs of value semantics, except as noted below > - Difficult to implement > + Cheap to copy around, will "divide" only upon mutation attempts > - Innocuous operations may throw/occasionally take a long time > > 3. Reference semantics > > - Hard to reason about: squirrel an array into an object, and way later > and farther it modifies the array and effects a change at long distance > - Long-distance effects may as well be some of the toughest bugs after > memory errors > + Cheap to copy > + Familiar to Java/C# refugees > - Less familiar to C++ refugees > - Potentially inefficient as people might start sprinkling copies in the > hope the eliminate bugs or chances of bugs > + const system helps: if a function doesn't change something just mark > it as const and you're home free > + immutable also helps: immutable data can never change so it can be > shared no problem. Not sure how interesting immutable containers are though. > - Implementing fast/unsafe semantics with reference semantics > effectively forces reference counting to be part of containers, which > complicates implementation. > > Any thoughts, just share! For the record, Walter has a bias in favor > of... I'll better don't bias you guys. > > One thing: it would be relatively easy to switch among semantics by > defining a wrapper such as Value!(T) or Ref!(T). So whatever choice we > make, it won't paint us into a corner. > > > Andrei
I'm a C++ refugee and value semantics make no sense to me. I always declared classes (as part of function declaration) in C++ with a &... Either T& or const T&. There were plenty of bugs where I messed up and forgot the &. D is nice in that it tries to simplify that. You yourself had issues with remembering ref parameters when implementing ranges!