www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: DMD 1.036 and 2.020 releases

reply Jason House <jason.james.house gmail.com> writes:
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.
Oct 21 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 21 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.




 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
Oct 21 2008
parent reply John Reimer <terminal.node gmail.com> writes:
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
Oct 21 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== 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



 -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.
Oct 21 2008
parent BCS <ao pathlink.com> writes:
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
 



 -JJR



 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.
Oct 21 2008