August 18, 2020
https://forum.dlang.org/post/ptgud7$16f6$1@digitalmars.com

On Monday, 26 November 2018 at 14:02:15 UTC, Andrei Alexandrescu wrote:
> 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

I am in disagreement.

The is expressions are complicated both for a developer and the compiler.

If one promotes a wrapper template that shows just that the way of expressing it is too complicated.

low level tools should be simple, because if they are not simple they can't be low-level.