Bill Baxter Wrote:

> On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright <newshound1@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.

On Wed, Oct 22, 2008 at 7:01 AM, Jason House <jason.james.house@gmail.com> wrote:
> Bill Baxter Wrote:
>
>> 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.
>

Yep, definitely shouldn't get rid of opIndexAssign.  It's still a nice advantage of D over C++ when you want to monitor and control all modifications to an array-like object.

But if the opIndex does return a ref, and an opIndexAssign has not been defined then I don't see why that opIndex shouldn't allow users to say   foo[10] = x.   Instead of *(&foo[10])=x;

--bb

Jason House wrote:
> Bill Baxter Wrote:
> 
>> On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
>> <newshound1@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

Hello Andrei,

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


This may not be a popular opinion, but I agree!

-JJR

== Quote from John Reimer (terminal.node@gmail.com)'s article
> Hello Andrei,
> > I think the entire operator paraphernalia is due for a serious overhaul.
> >
> > Andrei
> >
> This may not be a popular opinion, but I agree!
> -JJR

I'll second that.  D's operator overloading is a bit confusing because it's kind of grown rather than having been designed.  This should be fixed now, while breaking changes are still considered acceptable.

Reply to dsimcha,

> == Quote from John Reimer (terminal.node@gmail.com)'s article
> 
>> Hello Andrei,
>> 
>>> I think the entire operator paraphernalia is due for a serious
>>> overhaul.
>>> 
>>> Andrei
>>> 
>> This may not be a popular opinion, but I agree!
>> -JJR
> I'll second that.  D's operator overloading is a bit confusing because
> it's kind of grown rather than having been designed.  This should be
> fixed now, while breaking changes are still considered acceptable.
> 

Clean it up if you want to. But overall I like the *general* way it work.