• Stefan Koch (10/38) Aug 18 2020 https://forum.dlang.org/post/ptgud7$16f6$1@digitalmars.com

Stefan Koch <uplink.coder googlemail.com> writes:

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.