isArray and std.container.Array

[via Digitalmars-d-learn]

On Sunday, 28 September 2014 at 20:24:11 UTC, monarch_dodra wrote:
> 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();

The question is whether you want to call something "array-like" 
if it isn't stored contiguously in memory. Most algorithms don't 
depend on it, but it's a significant divergence from what isArray 
guarantees.