Questions about the slice operator

[Jacob Carlborg]

On 2012-04-04 19:09, Jonathan M Davis wrote:

> That might work, but it does make it so that ".." has very different meanings
> in different contexts, and I don't know that it really buys us much. iota
> already does them same thing (and with more functionality), just without the
> syntactic sugar. Also, we've had enough issues with moving AA's into druntime,
> that I don't know how great an idea this sort of thing would be (though it
> should be much simpler). It would certainly make some folks (e.g. Bearophile)
> happy though.

Yeah, we don't have to stop any releases for this. It's one of those 
features in the language that is not very consistent and sometimes that 
just a bit annoying.

>> This could then be taken advantage of in other parts of the language:
>>
>> class A
>> {
>> int opSlice (range r); // new syntax
>> int opSlice (size_t start, size_t end); // old syntax
>> }
>>
>> I think this would be completely backwards compatible as well.
>
> Except that opSlice already works with "..". What would this buy you?

Nothing, but that's how the language could have looked like if a first 
class range type had been added to the language a long time ago.

> It doesn't make sense to pass opSlice a range normally. Why treat this proposed
> "range" type any differently from any other range? This functionality already
> exists with the second declaration there. If we added a range type like this,
> I'd be inclined to make it __range or somesuch and not ever have its name used
> explicitly anywhere. It would basically just be syntactic sugar for iota
> (though it wouldnt' use iota specifically). I don't know what else you would be
> looking to get out of using its type specifically anywhere. That's not general
> done with other range types.

In this case "range" is just a start and end of a list of numbers, maybe 
"range" is not a good name IT conflicts with the concept of ranges.

No, instead we use templates like mad.

-- 
/Jacob Carlborg