std.complex

[Stewart Gordon]

On 03/01/2014 17:04, Joseph Rushton Wakeling wrote:
> On 03/01/14 14:32, Stewart Gordon wrote:
>> I wasn't asking for it to go beyond the existing complex
>> implementation or any other. I was proposing that the arbitrary
>> restriction be removed so that the implementation we already have
>> would work on them.
>
> Yes, but it isn't an arbitrary restriction.  Template constraints are
> fundamentally a promise to users about what can be expected to work.
> Integral types, or library types, won't work without significant
> modifications to the internals of the code.  It would be a false promise
> to relax those constraints.

But I believed the restriction to be arbitrary at the time I made my 
original point, hence my point.

<snip>
> Yes, it ought to be possible to redefine FPTemporary (or define an
> alternative) to determine proper internal temporaries for any
> "float-esque" case.  I was toying with something along the lines of,
>
>      template FPTemporary(F)
>          if (isNumeric!F || isFloatLike!F)
>      {
>          alias typeof(real.init * F.init) FPTemporary;
>      }
>
> ... where isFloatLike would test for appropriate floating-point-like
> properties of F -- although this is probably far too simplistic.

How can isFloatLike be implemented?

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

> E.g. how do you handle the case of a float-like library type
> implemented as a class, not a struct?

What's the difficulty here?

<snip>
> It doesn't matter if you document it as "This might not work", by
> providing the option you are still essentially saying, "This is an OK
> way to use the type."
>
> I think that's essentially an encouragement of bad code and a violation
> of the design principle that the easy thing to do should be the right
> thing to do.

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

>> Really, I was just thinking that somebody who wants a quick-and-dirty
>> hypercomplex number implementation for some app might try to do it
>> that way.
>
> I understand that, but quick-and-dirty solutions are often bad ones, and
> in this case, it just wouldn't work given the internals of Complex.

Addition, subtraction and multiplication would work.  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).

Stewart.