Short list with things to finish for D2

[Andrei Alexandrescu]

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