status of "isComplex" in traits ?? (we have isFloatingPoint, for example)

[james.p.leblanc]

On Wednesday, 18 August 2021 at 17:49:53 UTC, Paul Backus wrote:
> On Wednesday, 18 August 2021 at 17:36:48 UTC, H. S. Teoh wrote:
>> There's no need, you could just write:
>>
>> 	static if (is(T == Complex!U, U)) {
>> 		// You can refer to U here to get at the type Complex
>> 		// was instantiated with.
>> 	}
>>
>> This has the added benefit of unpacking the parameter U for 
>> you.
>
> Well, there's no need assuming you already know how to use is() 
> expressions to pattern-match types, which is a big assumption.
>
> IMO it would not be totally unreasonable to add an 
> std.complex.isComplex template for this purpose.

H.S Teoh:  I agree it is a simple thing to write your own.
And I really, really like your suggested solution of "unpacking
the U".  In fact, I am going to use this on a function I am
writing this evening.  Thanks!

But, there is a tiny downside of having to carry this around to 
all
your code bits(utilities modules / distribution / etc ...).

My thinking was that being complex **IS** exactly the same kind of
trait that being a floatingPoint, or being an integral is.

So, in that sense, it would extend present usage in std.traits (or
std.complex) to anyone doing numerical computation.

My recent experience of **not** finding *isComplex* was a bit
perplexing to be honest.  So, for now I am using the mir
lines of code in my own utilities module.  But, I thought
it would be fitting to find a default version in std.traits.

I am not really sure how to make a more serious inquiry to the
developers/maintainers of std.traits.

Thanks for your insights and suggestions.

Regards,
James