https://issues.dlang.org/show_bug.cgi?id=7102
Ivan Kazmenko <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Ivan Kazmenko <[email protected]> --- I'd say any polylogarithmic GCD algorithm would be better than none. Euclid (current) and Stein (binary) versions would be fine. >From a user's perspective: when I need a casual GCD for BigInts (I just did) and I find std.numeric throwing weird complaints at me, I can, realistically: * take std.numeric version and hack the complaint away, * write my own version of GCD. Each of these is error-prone. So, is the current situation really better than having a slow GCD right there in the library? If people complain about speed then, it can be improved, but a specialization error like now, seriously? "I have it, I know BigInt could be used with it, but I won't let you use it because - of all things - BigInt doesn't have a .min", that's just unfriendly. To have a base version working seems a step forward to me. Ivan Kazmenko. --
