status of "isComplex" in traits ?? (we have isFloatingPoint, for example)
james.p.leblanc
james.p.leblanc at gmail.com
Wed Aug 18 19:01:25 UTC 2021
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
More information about the Digitalmars-d
mailing list