Why is there no

- __traits(isArray, T)

alongside

- __traits(isStaticArray, T) and
- __traits(isAssociativeArray, T)

when dmd already has `ENUMTY.Tarray` alongside

- ENUMTY.Tsarray and
- ENUMTY.Taarray

and std.traits already has a wrapper for this at

https://dlang.org/phobos/std_traits.html#isDynamicArray

?

Should we add this new builtin trait and use it in std.traits.isDynamicArray?

If so, should we call it

- __traits(isDynamicArray) or
- __traits(isArray) or
- __traits(isArraySlice) or
- __traits(isSlice) or

something else?

On Monday, 26 November 2018 at 09:04:25 UTC, Per Nordlöw wrote:
> Why is there no
>
> - __traits(isArray, T)
>
> alongside
>
> - __traits(isStaticArray, T) and
> - __traits(isAssociativeArray, T)
>
> when dmd already has `ENUMTY.Tarray` alongside
>
> - ENUMTY.Tsarray and
> - ENUMTY.Taarray
>
> and std.traits already has a wrapper for this at
>
> https://dlang.org/phobos/std_traits.html#isDynamicArray
>
> ?
>
> Should we add this new builtin trait and use it in std.traits.isDynamicArray?
>
> If so, should we call it
>
> - __traits(isDynamicArray) or
> - __traits(isArray) or
> - __traits(isArraySlice) or
> - __traits(isSlice) or
>
> something else?

Yeah maybe just try, although i see some alias this implication in the current std.traits implementation. Adding a new trait is rarely a big deal as far as i could see in the past (i.e no big never endings discussions).

On Monday, 26 November 2018 at 09:28:37 UTC, Basile B. wrote:
> On Monday, 26 November 2018 at 09:04:25 UTC, Per Nordlöw wrote:
>> Why is there no
>>
>> - __traits(isArray, T)
>>
>> alongside
>>
>> - __traits(isStaticArray, T) and
>> - __traits(isAssociativeArray, T)
>>
>> when dmd already has `ENUMTY.Tarray` alongside
>>
>> - ENUMTY.Tsarray and
>> - ENUMTY.Taarray
>>
>> and std.traits already has a wrapper for this at
>>
>> https://dlang.org/phobos/std_traits.html#isDynamicArray
>>
>> ?
>>
>> Should we add this new builtin trait and use it in std.traits.isDynamicArray?
>>
>> If so, should we call it
>>
>> - __traits(isDynamicArray) or
>> - __traits(isArray) or
>> - __traits(isArraySlice) or
>> - __traits(isSlice) or
>>
>> something else?
>
> Yeah maybe just try, although i see some alias this implication in the current std.traits implementation. Adding a new trait is rarely a big deal as far as i could see in the past (i.e no big never endings discussions).

This would be a nice addition, imho.

As Basile B is saying, there is quite a bit of work done for the `isDynamicArray` implementation. If you have the time to drill down from https://github.com/dlang/phobos/blob/master/std/traits.d#L6618

I was expecting the `isArray` check to be something like `enum isArray(T) = is(T == U[], U)`

I would like to see this in the compiler traits :D

On Monday, 26 November 2018 at 10:53:25 UTC, Eduard Staniloiu wrote:
> I would like to see this in the compiler traits :D

https://github.com/dlang/dmd/pull/9014

On 11/26/18 4:04 AM, Per Nordlöw wrote:
> Why is there no
> 
> - __traits(isArray, T)
> 
> alongside
> 
> - __traits(isStaticArray, T) and
> - __traits(isAssociativeArray, T)


Thanks for bringing this to my attention, Per.

The core idea is to have __traits "primitive and ugly" and std.traits "convenient and nice". From that viewpoint, if isArray can be implemented as a library feature using primitives provided by traits, there is no need for making it.

> when dmd already has `ENUMTY.Tarray` alongside
> 
> - ENUMTY.Tsarray and
> - ENUMTY.Taarray

Justifying the feature by means of a detail in the compiler implementation is definitely undesirable.

> and std.traits already has a wrapper for this at
> 
> https://dlang.org/phobos/std_traits.html#isDynamicArray
> 
> ?

If the wrapper works well, use it and move on.


Thanks,

Andrei