Indexing with an arbitrary type

[Alex via Digitalmars-d-learn]

On Monday, 1 August 2016 at 15:51:58 UTC, Jonathan M Davis wrote:
> On Monday, August 01, 2016 15:25:59 Alex via 
> Digitalmars-d-learn wrote:
>> On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis 
>> wrote:
>> > If you want a template constraint that checks that a type 
>> > works with the index operator on a type, and you're not 
>> > restricting it to something like size_t, then you're just 
>> > going to have to check whether the expression is going to 
>> > compile. Also, that is incompatible with random access 
>> > ranges. Random access ranges are expected to work with 
>> > size_t, and while isRandomAccessRange isn't currently quite 
>> > that restrictive, it does check that r[1] compiles, so the 
>> > index operator is going to have to accept integers at 
>> > minimum. If you want a completely generic index operator, 
>> > and you want a template constraint for it, you're pretty 
>> > much going to have to test that it compiles. e.g.
>> >
>> > auto fun(I, T)(I index, T obj)
>> >     if(__traits(compiles, obj[index]))
>> > {
>> >     return obj[index];
>> > }
>> >
>> > or if you want a reusable template, you can do something like
>> >
>> > template isIndexable(I, T)
>> > {
>> >     enum isIndexable = __traits(compiles, T.init[I.init]);
>> > }
>> >
>> > auto fun(I, T)(I index, T obj)
>> >
>> >     if(isIndexable!(I, T))
>> > {
>> >     return obj[index];
>> > }
>> >
>> > Personally, I think that having code that accepts any type 
>> > that can be indexable with any type isn't a particularly 
>> > good idea, because odds are, it won't actually work, because 
>> > those
>> >
>> > different types will work quite differently (e.g. 
>> > associative arrays are indexable with stuff other than 
>> > size_t, but they're really not interchangeable with dynamic 
>> > arrays or static arrays, which use size_t). And anything 
>> > that wants to be interchangeable with a dynamic array or be 
>> > usable as a random access range should be using size_t to 
>> > index. But if you
>>
>> This is exactly what my question is about. I don't think, that 
>> it doesn't make sense (and isn't a good idea) to index with an 
>> arbitrary type, too.
>
> The issue is that the semantics have to be sufficiently similar 
> across the types that the code will work. And if your code is 
> doing much beyond indexing, it probably won't. But if it does 
> in your case, then great.
>
>> So, how I can define/design a type, which is not an 
>> int/size_t, but has one to be able to index with it?
>>
>> And if the __compiles trait is the way to go with... well then 
>> that's just how it is...
>
> You're pretty much going to have to go with some form of
> __traits(compiles, ...) to test the code that the code that you 
> want to code
> compiles. That's ultimately what a lot of traits do. And if 
> what you're
> looking to test is that obj[index] works where obj and index 
> are arbitrary
> types, what else would you be testing for anyway? You'd only 
> need to test
> for more beyond that if you were trying to further restrict the 
> types
> involved and/or to require that some other set of operations 
> compiled in
> addition to indexing.
>
> - Jonathan M Davis

Got it... Thanks :)