Philippe Sigaud wrote:
On Tue, Apr 20, 2010 at 11:06, Lars Tandle Kyllingstad
<[email protected] <mailto:[email protected]>> wrote:
Does Complex!BigInt (or Complex!int, for that matter) *ever* make
sense? I mean, yes, it *sounds* cool, and I'm normally against
introducing gratuitous constraints on functionality, but in this
case I think I prefer restricting T to real number types.
Have in mind that not only will one have to disable (or introduce
special cases for) abs() and arg(), but also some of the operations,
in particular division and exponentiation.
It all sounds like more work, more maintenance, more complex code
(hur hur), for very little or no benefit.
I completly agree, and wasn't trying to sell Complex for any integral
type! My only suggestion was to use a generic template to determine what
operators were supported by a type, based on your suggestion to use
compile-time interfaces, à la std.range.
I was using BigInt as non-built-in numeric type, the only one available
on Phobos.
Ok, it seems I understood you too literally. I think we mostly agree
then. Ideally, the constraint on Complex!T should act as a compile-time
interface that checks whether T *behaves* like a floating-point type.
However, in this case I personally think Complex!T should work equally
well for all T or not at all, and for the time being that means using
isFloatingPoint.
But then I thought that the compiler already checks at compile-time that
the operations are possible, so I'm not so certain about the need for
such a template. Maybe as a way to document the code?
That, and for error messages that are easier to understand and track down.
Sorry for the noise, I'll let you continue your good work.
Nono, don't be. Feedback is always good. :) Like I said, I just think
it's better to start with a tight constraint and relax it if it turns
out that that's what people want.
-Lars
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
