DMD 1.036 and 2.020 releases

[Andrei Alexandrescu]

Jason House wrote:
> Bill Baxter Wrote:
> 
>> On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
>> <newshound1 at digitalmars.com> wrote:
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.036.zip
>>>
>>> The 2.0 version splits phobos into druntime and phobos libraries (thanks to
>>> Sean Kelly). This will enable both Tango and Phobos to share a common core
>>> library.
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.020.zip
>>>
>>> There are a lot of structural changes that go along with this, so expect
>>> some rough patches with this release. It may take a followup release to file
>>> them down. There's also some renaming of imports and function names, as a
>>> compromise with Tango names.
>> Wao!  Missed this at first:
>>
>> class Foo
>> {
>>     ref int getref() {
>>         return m_int;
>>     }
>> private:
>>     int m_int = 23;
>> }
>>
>> void main() {
>>     auto foo = new Foo;
>>
>>     writefln(foo.getref);
>>     foo.getref() = 7;
>>     writefln(foo.getref);
>> }
>> //Outputs:
>> //23
>> //7
>>
>> It works!  This is maybe even bigger news than cure for TangoPhobia!
>>
>> But I think maybe more documentation is needed in the Ref returns
>> section regarding how this affects opIndex.
>>
>> class Foo
>> {
>>     this() {
>>         m_arr.length = 10;
>>         foreach(i, ref a; m_arr) { a=i;}
>>     }
>>     int[] array() {
>>         return m_arr;
>>     }
>>     ref int opIndex(size_t idx) {
>>         return m_arr[idx];
>>     }
>>
>> private:
>>     int[] m_arr;
>> }
>>
>> void main() {
>>     auto foo = new Foo;
>>     foo[3] = -99;
>> //hello.d(44): Error: operator [] assignment overload with opIndex(i,
>> value) illegal, use opIndexAssign(value, i)
>> //hello.d(44): function hello.Foo.opIndex (uint idx) does not match
>> parameter types (int,int)
>> //hello.d(44): Error: expected 1 arguments, not 2
>> }
>>
>> Apparently using opIndex with ref return is not allowed as a way to
>> set an index.
>> This works though:
>>
>>     *(&foo[3]) = -99;
>>
>> Is there a good reason why it shouldn't be possible to use opAssign as
>> a replacement for opIndexAssign?
>>
>> --bb
> 
> opindexAssign will still be needed when opindex has a non-ref return type.

I think the entire operator paraphernalia is due for a serious overhaul.

Andrei