On Monday, September 26, 2011 13:47 Paul D. Anderson wrote: > bearophile Wrote: > > Time ago I've asked to use BigInt with iota too (no D changes needed > > here): http://d.puremagic.com/issues/show_bug.cgi?id=6447 > > > because currently this doesn't work (std.traits.isIntegral needs to change, and there changes needed in iota too, because it can't use the current std.traits.unsigned, because a BigInt has no ".min" field): > Yes, it would be nice to allow isIntegral, isArithmetic, etc. to recognize > library types and not just built-in types. > > This would be helpful for, for instance, rational numbers and decimal > numbers (BigDecimal and decimal32, decimal64, decimal128. > > As an aside, for those who are interested, the Decimal library implementing > the numbers listed above is very near completion. Just some testing and > tidying to do before it can go on the review queue.
I think that we need to be _very_ careful about the implications of making isIntegral and other similar traits functions work with non-primitive types. There could _easily_ be code which assumes that it's going to get primitive types when isIntegral is true. Take the integer swapping code in std.bitmanip. It would fail miserably if all of a sudden BigInt worked with isIntegral, and you tried to use BigInt with it. I can see we might want to have isIntegral work with BigInt, but I do _not_ think it's necessarily the case that it's actually a good idea. We need to be careful about the implications of all of that and make very informed decisions about the changes that we make to std.traits, or a lot of code is going to break in non-obvious ways. - Jonathan M Davis
