digitalmars.D - status of "isComplex" in traits ?? (we have isFloatingPoint, for
- james.p.leblanc (25/25) Aug 18 2021 Dear All,
- H. S. Teoh (10/21) Aug 18 2021 There's no need, you could just write:
- Paul Backus (5/11) Aug 18 2021 Well, there's no need assuming you already know how to use is()
- james.p.leblanc (21/35) Aug 18 2021 H.S Teoh: I agree it is a simple thing to write your own.
- jmh530 (7/27) Aug 18 2021 The implementation that the OP referenced in mir-core works for
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 2021
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 2021
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 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: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, JamesThere'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 2021
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: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.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
Aug 18 2021