DMD 0.177 release

[Kevin Bealer]

== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail at erdani.org)'s article
> Kevin Bealer wrote:
...
> > 2. Return S* and let the compiler apply the "*".
> >
> >     S* opIndex(int i);
> >     Compiler silently transforms foo(x[i]) into foo(*x[i])
> This is also (probably more) unsatisfactory. People will be able to
> index and obtain lvalues, but will be unable to return something
> assignable from a function:
>
> ++s[a]; // possible through a compiler hack
> ++s(a, b); // impossible

I missed this possibility.  In order to solve just this next step { ++s(a, b); },
it seems like D would need something that copies like a pointer to either a struct
or class reference, but automatically turns into (or acts like) a regular
reference or LValue when something like ++ is applied.  This means something in
between a pointer and an LValue.

I'll keep calling it 'ref' for now.  I think to get the semantics we'd expect it
needs these properties:

1. For struct, it can be returned from a method/function or passed as an (inout)
argument one or more times without causing any struct-copy to happen, and still
referring to the original class reference (not just the original class).

2. For class, it can be used to modify the original object reference itself, i.e. for:

ref C X::opIndex(int i);
foo(inout C);
foo(x[i]) should have the potential to modify the reference in the i'th location
of x, by replacing with a different C object.

3. It should autoconvert to (or behave like) a regular LValue when something like
++ or += happens.  Of course if += is called and opAddAssign() returns "ref T",
then the returned reference would propagate a ref to the same original entity.

4. Due to #3, it cannot support things like pointer arithmetic (which is perfectly
okay).  Or assignment to the ref itself (the assign and other operations would by
applied to the referred object of course).

It's also probably convertable to a pointer via "&", i.e. address-of returns a
pointer-to-original instead of pointer-to-ref.  I guess this means it's impossible
to get an address of the "ref" type itself except via trickery?


I kind of hate to say it, but given all this, how far am I from describing a C++
"&" type?  Is there anything the C++ type does that isn't in the above list?
(Other than the new proposal for '& &' references I guess, which seems unnecessary
for D.)

Kevin