On Wed, Aug 18, 2021 at 05:22:31PM +0000, james.p.leblanc via Digitalmars-d wrote:
> Dear All,
> 
> We indeed have **"isFloatingPoint"**, and **"isIntegral"** in std.traits.
> 
> But, what is the status/thinking about having **"isComplex"** included in std.traits (... or ... potentially std.complex ??).
> 
> I ask because, there are recommendations that we should start using Complex!double, Complex!float ... so perhaps this is a good time for a formal home for "isComplex" ??

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.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

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.

On Wednesday, 18 August 2021 at 17:36:48 UTC, H. S. Teoh wrote:
> On Wed, Aug 18, 2021 at 05:22:31PM +0000, james.p.leblanc via Digitalmars-d wrote:
>> Dear All,
>> 
>> We indeed have **"isFloatingPoint"**, and **"isIntegral"** in std.traits.
>> 
>> But, what is the status/thinking about having **"isComplex"** included in std.traits (... or ... potentially std.complex ??).
>> 
>> I ask because, there are recommendations that we should start using Complex!double, Complex!float ... so perhaps this is a good time for a formal home for "isComplex" ??
>
> 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.
>
>
> T

The implementation that the OP referenced in mir-core works for any struct or enum that has re/im fields with floating point numbers (or something like that) with a fallback for built-in ones. Functions that use mir-core's isComplex can accept phobos complex numbers or other user-defined complex numbers (that fulfill the requirement), including the deprecated built-in ones.

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