On 02/01/2014 19:32, Joseph Rushton Wakeling wrote:
On Thursday, 2 January 2014 at 18:12:56 UTC, Stewart Gordon wrote:
Then why not just disable division if it's a non-float type, rather
than preventing the whole complex template from being used with that
type? This is like cutting off somebody's arm because they have a sore
thumb.
Because that also seems to me to be an unpleasant option. A complex
number implementation that fails to support ordinary arithmetic
operations in all circumstances is pretty non-intuitive and will
probably lead to unpleasant bugs in users' code.
The compiler rejecting the code is the most pleasant bug that's possible
IMO.
Moreover, we have no way in the general case of determining whether T
is an integral type, a library float-esque type, or (for example) a
Galois field type. So disabling it _just in case_ division doesn't
work is crazy. There must be better ways to do it.
I don't follow your point here. We can constrain T however we see fit.
The point isn't to have some perfect representation of every
mathematical possibility, it's to have useful code that serves a good
range of use-cases while being robust and easy to maintain.
Not being overly restrictive in what types you will allow it to be used
with is an important part of serving a good range of use cases.
<snip>
What do you mean by "in the context of", exactly? Restricting it to
some float-esque type that is in Phobos would still be overly
restrictive.
No, I mean that until you have at least one actual float-esque type to
test with, it is probably unwise to relax the template constraints that
currently mandate built-in FP types.
I'm sure we have a small handful already. We just need to find them.
For instance, given the time I could probably dig up my rational number
implementation and update it to current D.
It would, but removing the restriction would simplify the
implementation of Hypercomplex(T) by enabling it to be a wrapper for
Complex!(Complex!T).
And complicate the implementation of Complex itself, for the sake of a
likely very marginal special interest that could be supported quite well
by an independent type.
How would it complicate the implementation? Removing the undocumented
rule whereby Complex!(Complex!T) folds to Complex!T would be a slight
simplification.
Maybe the right course of action is to have a parameter to the template
that suppresses the type restriction and the folding rule, so that
people who want to use it on a type that might not work properly can do
so. This would be a relatively small change.
Stewart.
