Hi,

What is the difference between T[] opIndex() and T[] opSlice(), which haven't parameters?

struct S(T)
{
    T[] arr;
    
    T[] opIndex() => arr[];/*
    T[] opSlice() => arr;//*/
}

alias Type = int;
void main()
{
    auto s = S!Type([1,2,3]);
    auto arr = s[]; // calls s.opIndex()
    
    assert(arr == [1,2,3]);
    assert(is(typeof(arr): Type[]));
}

Also, is it correct to use [] when returning?

Thanks...

On Sunday, 1 October 2023 at 17:41:08 UTC, Salih Dincer wrote:

Here, the opIndex() is proposed and an example of parameterized the opSlice() is given for multidimensional arrays. Like there's no difference, huh?

Puff :)

On 10/1/23 1:41 PM, Salih Dincer wrote:

None. It used to be that opSlice was the only way, and the mechanisms opSlice uses are still valid.

-Steve

On Monday, 2 October 2023 at 02:01:34 UTC, Jonathan M Davis wrote:

Overloading has nothing to do with indexing, so I'll use opSlice.

import std.stdio;
import std.range;

struct Matrix(T)
{
  private T[][] elements;
  size_t length;
  T* ptr;

  this(size_t length)
  {
    this.length = length * length;
    size_t m = T.sizeof * this.length;
    ubyte[] arr = new ubyte[](m);

    ptr = cast(T*)arr.ptr;
    m /= length;

    foreach(i; 0 .. length)
    {
      size_t n = i * m;
      elements ~= cast(T[])arr[n .. n + m];
    }
  }

  ref T opIndex(size_t i)
  in(i < length)
    => ptr[i];

  auto opDollar() => length;
  auto opSliceAssign(T value, size_t a, size_t b)
  in(a <= length && b <= length)
    => ptr[a..b] = value;

  auto opSlice() => elements;
  auto opSliceAssign(T value)
  {
    foreach(i; 0 .. length)
    {
      ptr[i] = value;
    }
  }
}

void main()
{
  auto arr = Matrix!double(3);
  size_t n;

  foreach(value; iota(0.1, 1, 0.1))
    arr[n++] = value;
  
  arr[].writefln!"%-(%-(%s %)\n%)\n";
  
  arr[0..$/2] = 0;   // reset a slice

  arr[].writefln!"%-(%-(%s %)\n%)\n";

  arr[] = 0;             // reset all
  
  arr[].writefln!"%-(%-(%s %)\n%)\n";
  
  arr[6..9] = 1;       // set a slice
  arr[].writefln!"%-(%-(%s %)\n%)\n";
}

SDB@79

On Sunday, 1 October 2023 at 17:41:08 UTC, Salih Dincer wrote:

T[] opSlice() is the D1 version and exists only for backwards compatibility. You should use T[] opIndex() in new code.

On Monday, 2 October 2023 at 16:05:39 UTC, Paul Backus wrote:

Forgive me for asking again, I think opSliceAssign(T value) has also been improved, right?

   // ...

   auto opSlice()
   {
     return elements[];
   }

   auto opSliceAssign(T value)
   {
     foreach(i; 0 .. length)
     {
       ptr[i] = value;
     }
   }
 }

In an old version (for example, v2.0.83), the code you implemented in the places where Slice is written above works as desired. In the most current versions, the parameterized opIndexAssign(T value) gives the error:

Source: https://run.dlang.io/is/TPAg5m

Thanks...

SDB@79

On Monday, 2 October 2023 at 20:34:11 UTC, Salih Dincer wrote:

I don't know what's wrong in your example but this works for me:

struct S
{
    void opIndexAssign(int value)
    {
        import std.stdio;
        writeln("assigned ", value);
    }
}

void main()
{
    S s;
    s[] = 7;
}

On Monday, 2 October 2023 at 20:42:14 UTC, Paul Backus wrote:

struct S
{
    void opIndexAssign(int value)
    {
        import std.stdio;
        writeln("assigned ", value);
    }
}

void main()
{
    S s;
    s[] = 7;
}

So in the example linked by Salih, the opIndex returns a ref, which is a valid mechanism to properly do a[0] = val;. However, since opIndexAssign exists, the compiler expects that to be used instead.

Essentially, by naming the slice assign the same operator as index assign, you have eliminated the possibility for ref assignment via indexing.

Now, you can define a further opIndexAssign(T val, size_t idx). However, now you lose capabilities like a[0]++, which I don't think has a possibility of implementing using an opIndex operator, and it would be pretty ugly if you had to.

This seems like a design flaw in the opIndex overloading changes. I would stick with opSliceAssign if faced with this problem (glad it still works!)

It could also be considered a bug but I don't know the overload implications.

-Steve