www.digitalmars.com         C & C++   DMDScript  

D - Operator overloading for array indexing and slicing.

reply Patrick Down <Patrick_member pathlink.com> writes:
http://www.digitalmars.com/d/future.html

Walter, I noticed in the future document that you are going
to add operator overloading for array indexing and slicing.

I hope that you will consider doing separate "get index"
and "set index" operations.

class Foo
{
int getidx(int index)
{ 
//...
}

Foo setidx(int index, int value)
{ 
//...
}
}
Jan 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
Why? I was thinking of the index function returning a pointer, which can
then be used as either an lvalue or an rvalue.

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b0p40t$2q81$1 digitaldaemon.com...

 http://www.digitalmars.com/d/future.html

 Walter, I noticed in the future document that you are going
 to add operator overloading for array indexing and slicing.

 I hope that you will consider doing separate "get index"
 and "set index" operations.

 class Foo
 {
 int getidx(int index)
 {
 //...
 }

 Foo setidx(int index, int value)
 {
 //...
 }
 }
Jan 23 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
The pointer approach does not let you do any checking or
processing of the value being assigned.


In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...

Why? I was thinking of the index function returning a pointer, which can
then be used as either an lvalue or an rvalue.

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b0p40t$2q81$1 digitaldaemon.com...

 http://www.digitalmars.com/d/future.html

 Walter, I noticed in the future document that you are going
 to add operator overloading for array indexing and slicing.

 I hope that you will consider doing separate "get index"
 and "set index" operations.

 class Foo
 {
 int getidx(int index)
 {
 //...
 }

 Foo setidx(int index, int value)
 {
 //...
 }
 }
Jan 23 2003
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Patrick Down wrote:

 In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...


Why? I was thinking of the index function returning a pointer, which can
then be used as either an lvalue or an rvalue.


 The pointer approach does not let you do any checking or
 processing of the value being assigned.


Whoa, I hadn't thought that Walter might do that.  Yes, both get and set 
are needed or you can't do many things.  For example:

- You might return zero when the user reads out-of-range of an array but 
resize the array if he assigns to it (like how the associative arrays 
work).

- Insertion into the array might cause some simple refcounting to be 
done, or require further registration.

- The actual accepted values of the array may be more limited than what 
the public interface allows.  IOW, DBC is needed.

- If you return a static zero pointer from the array index while trying 
to do something like the first item here, it could easily get modified 
and you would have no way to control that.  By the time you can report 
it as an error, the guilty code will have been long gone.

- The array might be entirely ephemeral, with values extrapolated at 
runtime.  The assignment might not be a valid pointer by the time the 
user tries to do so.

- The array might be shared and require a synchronized block to assign 
properly, or go through conflict resolution.

All of these problems are easily handled by separate getitem and setitem 
methods.  C++ made a mistake thinking it could be so simple.

This would also be a good opportunity to start allowing user-handled 
rectangular arrays.  I don't want the language to support them.  I just 
want:

     x [a, b];

To be turned into:

     x.getitem (a, b);

For slices, I think we need to bite the bullet and go with:

     struct Range
     {
         int start;
         int end;
         bit startImplicit;
         bit endImplicit;
     }

     x [a .. b, c];

     x.getslice ((Range) [{a, b, false, false}, {c, c, false, false}]);
Jan 23 2003
next sibling parent Patrick Down <pat codemoon.com> writes:
Burton Radons <loth users.sourceforge.net> wrote in
news:3E30C5D9.9070500 users.sourceforge.net: 


 
 
 Patrick Down wrote:

 In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...


Why? I was thinking of the index function returning a pointer, which
can then be used as either an lvalue or an rvalue.


 The pointer approach does not let you do any checking or
 processing of the value being assigned.


 
 Whoa, I hadn't thought that Walter might do that.  Yes, both get and
 set are needed or you can't do many things.  For example:


[snip]

Yes, those are all good reasons.  In C++ you have to have
operator[] return an intermediate helper class to accomplish
any of those tasks.  


 
 This would also be a good opportunity to start allowing user-handled 
 rectangular arrays.  I don't want the language to support them.  I
 just want:
 
      x [a, b];


I really like this syntax better than dealing with
arrays of arrays.
Jan 23 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3E30C5D9.9070500 users.sourceforge.net...

 Patrick Down wrote:
  > In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...
  >
  >>Why? I was thinking of the index function returning a pointer, which


can

  >>then be used as either an lvalue or an rvalue.
  >

 The pointer approach does not let you do any checking or
 processing of the value being assigned.


 Whoa, I hadn't thought that Walter might do that.  Yes, both get and set
 are needed or you can't do many things.  For example:


But then, as Antti said, how do you support a[i] += e; ?
Mar 05 2003
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:3E30C5D9.9070500 users.sourceforge.net...
 

Patrick Down wrote:

 In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...


Why? I was thinking of the index function returning a pointer, which






 
 can
 

then be used as either an lvalue or an rvalue.





The pointer approach does not let you do any checking or
processing of the value being assigned.


Whoa, I hadn't thought that Walter might do that.  Yes, both get and set
are needed or you can't do many things.  For example:


 
 But then, as Antti said, how do you support a[i] += e; ?


The same way as properties:

    a.setitem(i, a.getitem(i) + e);

Although evaluating "i" and "a" but once, of course.

This does keep the index from being treated as an lvalue.  I think 
that's a reasonable tradeoff, considering that the C++ method makes so 
much else impossible.
Mar 06 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b46udj$2tsb$1 digitaldaemon.com...

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:3E30C5D9.9070500 users.sourceforge.net...

 Patrick Down wrote:
  > In article <b0pm6a$3o8$1 digitaldaemon.com>, Walter says...
  >
  >>Why? I was thinking of the index function returning a pointer, which


 can

  >>then be used as either an lvalue or an rvalue.
  >

 The pointer approach does not let you do any checking or
 processing of the value being assigned.


 Whoa, I hadn't thought that Walter might do that.  Yes, both get and set
 are needed or you can't do many things.  For example:


 But then, as Antti said, how do you support a[i] += e; ?


seems to me to be a good argument for a reference type, (which implicitly
exists already with inout params and objects)
Mar 06 2003
prev sibling parent Antti Sykari <jsykari gamma.hut.fi> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b0p40t$2q81$1 digitaldaemon.com...

 I hope that you will consider doing separate "get index"
 and "set index" operations.






Walter says...

Why? I was thinking of the index function returning a pointer, which can
then be used as either an lvalue or an rvalue.




Patrick Down <Patrick_member pathlink.com> writes:

 The pointer approach does not let you do any checking or
 processing of the value being assigned.


On the other hand, if you can access the value only via get/set
methods, you cannot pass the value via out/inout reference parameter
to a function.  (Since you just cannot get the reference to that
object.)  Things like += essentially act like a member function, which
essentially acts like a function with one inout and one in parameter.

I think that both cases should be allowed.  Some containers would not
like their parameters passed around by reference (because everyone
could change them without going through setidx) and other containers
would not need to worry about that.  So I propose that by default
things that would support the operator [] should be able to provide:

T getidx(int index);
void setidx(int index, T value);

If that is the case, it's forbidden to pass the value by reference and
things like "a[5] += 2" must be translated to "a[5] = a[5] + 2".

However, if some container likes to give uncontrolled lvalue access to
its data, it can provide

T* getidx(int index);

The idea that getidx and setidx can get several parameters is nice,
too.  Reminds me of good old function call operator syntax in C++.

-Antti
Jan 23 2003