Suppose I have a data structure encoding sequence lengths:

seq1: 0 1 2 ... N
seq2: 0 1 2 3 4 ... M
seq3: 0 1 ... P

I would like to write opIndex and opDollar to support the notation obj[seq, x .. $] to retrieve sequences.

However, given that opDollar is templated on dimension (always 1 in this example) and has no information calling function's context/dimension 0 parameter, this seems impossible.

Am I missing an easy solution?

Kind regards

On 10/1/20 10:34 PM, James Blachly wrote:
> Suppose I have a data structure encoding sequence lengths:
> 
> seq1: 0 1 2 ... N
> seq2: 0 1 2 3 4 ... M
> seq3: 0 1 ... P
> 
> I would like to write opIndex and opDollar to support the notation obj[seq, x .. $] to retrieve sequences.
> 
> However, given that opDollar is templated on dimension (always 1 in this example) and has no information calling function's context/dimension 0 parameter, this seems impossible.
> 
> Am I missing an easy solution?

This seems like an oversight. But it's not impossible.

Just curry the information to the receiver. opDollar doesn't have to return a size_t.

Something like:

struct FromEnd
{
  ptrdiff_t offset;
  FromEnd opBinary(string s, T)(T val)
  {
      mixin("return FromEnd(offset " ~ s ~ " val);");
  }
}

struct MyStructure
{
   FromEnd opDollar(size_t col)() if(col == 1) { return FromEnd.init; }
}

And then inside your opIndex, you have to handle that type specially according to context.

The saving grace here is that opDollar doesn't exist except in an indexing operation, so you don't need to worry about it except in that context. opDollar is really kind of a hacky way to do this. It was added back when multi-dimensional indexing was not yet solid.

-Steve

On 10/2/20 9:32 AM, Steven Schveighoffer wrote:
> This seems like an oversight. But it's not impossible.

Thank you Steve. Is there any chance that this mechanism will ever be revised? Presumably it would require a DIP.

> Just curry the information to the receiver. opDollar doesn't have to return a size_t.

This is indeed pretty clever; I would not have ever though to have opDollar return a non-integral value. This again suggests the whole thing needs to be revised, but this will work for now -- thanks again!

On 10/2/20 1:24 PM, James Blachly wrote:
> On 10/2/20 9:32 AM, Steven Schveighoffer wrote:
>> This seems like an oversight. But it's not impossible.
> 
> Thank you Steve. Is there any chance that this mechanism will ever be revised? Presumably it would require a DIP.

The problem is, how do you pass enough context to the opDollar? The nice thing about opDollar is it's a simple mechanism. But as a simple mechanism, it's hard to say how to give it enough context in this case. In this specific case, you would need to know the index of the first parameter. But what if the first parameter depended on the index of the second? Really, you need opIndex to get the whole expression, with the dollar sign being processed there. But that's really hard to do, because now you are delaying the expression evaluation until later.

What I meant by an oversight is, at one point, opDollar just was a single property. And opIndex did not take a slice parameter, but rather you just had opSlice(beg, end), which wasn't a template. The multi-parameter version of opIndex (and the column-specialized version of opSlice version) was added to aid in building the Mir library (I think), and I don't know if anyone brought up the possibility of a jagged array like this.

> 
>> Just curry the information to the receiver. opDollar doesn't have to return a size_t.
> 
> This is indeed pretty clever; I would not have ever though to have opDollar return a non-integral value. This again suggests the whole thing needs to be revised, but this will work for now -- thanks again!
> 

I think this is probably the best solution you are going to get. Maybe someone already has done something like this and has a better answer? Maybe Mir does something like this too, I'd take a look at it if I were you.

Long ago, I used opDollar to return something other than a size_t for dcollections, which worked awesome. I had asked for an opCaret, so that you could use slicing from beginning when `0` isn't the first element.

Like imagine a RBTree, I might like to say "range of all elements up to key 5" like rbt[^ .. 5] instead of rbt[rbt.begin .. 5].

But opCaret was deemed to be not useful enough. Oh well.

-Steve