Can opDollar support a jagged 2D array?

Steven Schveighoffer schveiguy at gmail.com
Fri Oct 2 17:46:36 UTC 2020


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


More information about the Digitalmars-d-learn mailing list