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.
