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.
