opIndexLvalue (was: Short list with things to finish for D2)

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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