== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > dsimcha wrote: > > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > >>> 2. After thinking about this some more, the big issue I see is ref > >>> opIndex. We > >>> can either: > >>> a. Disallow it for both UniqueArray and ArrayBuilder. > >>> b. Allow it for both UniqueArray and ArrayBuilder and accept > >>> that a sufficiently dumb programmer can invalidate the > >>> guarantees of UniqueArray by taking the address of one of the > >>> elements and saving it somewhere. Probably a bad idea, since > >>> assumeUnique() already works for the careful programmer, and > >>> UniqueArray is supposed to provide ironclad guarantees. > >>> c. Don't define opIndex in the abstract base class at all, thus > >>> making Array almost useless as an abstract base class. > >> Welcome to my demons :o). > >> One possibility that I thought of for a long time would be to disallow > >> taking the address of a ref. That reduces the scope of the problem but > >> doesn't eliminate it: > >> void main() { > >> auto a = new UniqueArray(10); > >> fun(a[0], a); > >> } > >> void fun(ref int a, UniqueArray b) > >> { > >> auto imm = b.toImmutable(); > >> // here a is a mutable alias into an immutable array!!! > >> } > >> So that doesn't work, but I thought I'd mention it :o). > >> Another possibility is to expose opIndex to return by value and also > >> opIndexAssign that sets the value. That would be a no-no in C++ because > >> copying is arbitrarily expensive, but I have a feeling that in D it is > >> sensible to consider and foster that all objects should be defined to be > >> cheap to copy (e.g. refcounting, COW etc.) If we go by the notion that > >> in D we can always assume copy costs are reasonable, this last > >> possibility would work. With the newfangled operators, it would even > >> work beautifully because you can do all sorts of things like a[1] += 4 > >> without ever exposing a ref to the user. > >> Andrei > > > > I wonder if it would be feasible to allow overloading on ref vs. non-ref > > return. > > Technically this would be overloading on return type, but without many of > > the > > practical problems. If the return value is used as an lvalue, the ref > > return > > function gets called. If the return value is only used as an rvalue, the > > non-ref > > function gets called. > > > > This would allow return by value to be defined in the base class and return > > by > > reference to only be defined in ArrayBuilder. > It has been discussed. Overloading is not necessary - Walter said > defining opIndex and opIndexLvalue and having the compiler call the > appropriate one is possible. > Andrei
Well, given that Walter's plate is pretty full, how hard would it be to implement this? I'll probably prototype my ArrayBuilder w/ pure value return and add in opIndexLvalue stuff if/when it becomes available. Also, are we ever going to do anything about vconst (DIP2)? For now, I've just been ignoring this issue when I write containers and writing them as if const does not exist, but this is obviously not the correct thing to do. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2