www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - status of "isComplex" in traits ?? (we have isFloatingPoint, for

reply james.p.leblanc <james.p.leblanc gmail.com> writes:
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 is a discussion here: https://wiki.dlang.org/Is_expression .

Also, a different version is found in the 
mir-core-master/source/mir/internal/utility.d
(with a dependency on enum "hasField" in file 
source/mir/reflection.d

I also see some evidence of something similar in rt/core ... but 
is was
unclear to me.

Thoughts?

Regards,
James

PS  Apologies in advance if this is the improper place for my 
post.
Just redirect me to proper place and I'll learn.
Aug 18
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 18
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
Aug 18
parent james.p.leblanc <james.p.leblanc gmail.com> writes:
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
Aug 18
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 18