std.complex

[Joseph Rushton Wakeling]

On 03/01/14 21:21, Stewart Gordon wrote:
> How can isFloatLike be implemented?

I'm not sure.  It's something that needs to be thought about and of course it 
also depends on whether you want it to test just for basic properties, or 
whether it is supported by mathematical operations (sin, cos, abs, exp, etc.).

I think testing for basic properties should be enough, because if mathematical 
functions are needed but not supported, there will be a compilation error anyway.

> And how can we test for bigint or Galois field types?

For BigInt, it's conceivable to define an isIntegerLike template (David Simcha 
did this for his std.rational) that will handle library as well as built-in 
integral types.

For Galois field types, I suggest that there needs to be an implementation 
before one talks about how to support them in std.complex.

> There are already violations of this principle in D, such as being able to cast
> away const.

Casting away const has valid applications and is a bit different from allowing 
the user to manually ignore template constraints on a library type, which will 
most likely almost always lead to problematic behaviour.  I'm not aware of any 
library type in Phobos that does this, and if you _really_ want to override the 
template constraints, you can always copy and modify the code.  Then, if it 
turns out to work well, you can submit patches to allow that case in Phobos too.

> Addition, subtraction and multiplication would work.

They wouldn't, because when you relaxed the template constraints to allow 
Complex!(Complex!T), the code would fail to compile.  And I don't think you 
should correct that by stripping out basic arithmetic operations.

> So the programmer could just copy the code and reimplement division and exponentiation so that they work
> (or just get rid of them if they aren't needed).

As I keep saying, you're asking for extra complication to be added to a type 
that supports its intended (probably the vast majority of) use cases well, for 
the sake of a niche use case _that can be implemented without any problem as an 
entirely independent type_.

What you perceive as conceptual/notational elegance -- Complex!(Complex!T) -- 
isn't worth it.