isArray and std.container.Array

[monarch_dodra via Digitalmars-d-learn]

On Sunday, 28 September 2014 at 19:06:09 UTC, Marc Schütz wrote:
> On Sunday, 28 September 2014 at 16:12:53 UTC, Meta wrote:
>> On Sunday, 28 September 2014 at 08:01:00 UTC, Nordlöw wrote:
>>> Is there a reason why isArray!T doesn't match T when T is a 
>>> std.container.Array? I'm asking because after looking into 
>>> msgpack-d because of
>>>
>>> http://forum.dlang.org/thread/aclapseyptgcwntdavwt@forum.dlang.org#post-aclapseyptgcwntdavwt:40forum.dlang.org
>>>
>>> I realized that this is the reason why msgpack doesn't 
>>> correctly pack std.container.Array.
>>
>> It's just an oversight in isArray as far as I can tell. I 
>> don't know if there's any specific reason that Array is not 
>> considered an array.
>
> I don't think so. std.container.Array is just a data structure 
> that behaves like an array, but there could be countless other 
> user defined data structures. It should not get preferred 
> treatment over those other types. At most, isArray could check 
> for the presence of .length, .ptr and indexing/slicing. But I 
> think isArray was intended specifically for built-in arrays. 
> It's description "is an array (static or dynamic [...])" is 
> probably meant to express that, because it lists static and 
> dynamic arrays, but doesn't mention array-like containers.

Yes, everything here is correct.

Interestingly though, "Array" is not actually "array-like" (it's 
not a range, it doesn't slice), however "Array.Range" *is* an 
array-like structure.

In regards to "isArrayLike", it would probably be more 
interesting to instead integrate it as a "isRandomAccessRange" 
range refinement, which would also allow "opSlice" operations, eg 
(myRange[0 .. 3] = 5).

As for ".ptr", I think no range *trait* should expose (require) 
that, as it would most probably be an underhanded way to leak 
some abstraction, which would be better expressed as a direct 
call *prior*, rather than a range proper. EG:
myRange.ptr[0 .. 10].doSomeOperation();