Don: > As I said when I closed that post, it is _impossible_ for BigInt to > always behave the same as int. One example: > > byte c = x & 0x7F; > > This compiles if x is an int. It doesn't compile if x is a BigInt. > > BigInt's job is to behave like a Euclidean integer, not to be a drop-in > replacement for built-in integer types.
As I have said in the first post of this thread I am not asking for impossible things: > While multi-precision numbers are not the fixed size integers, it is wise to > give > multi-precision numbers the same rules and usages of the normal fixed size > integers > _everywhere this is possible and handy_. This has some advantages like: > - Reduces the cognitive burden to remember where they differ; > - Allows for less work to adapt routines that work with integers to work with > BigInts. This is handy for generic code and for manual translation of code. > > I have said everywhere this is possible and handy, because this is not always > possible. You can't use a BigInt to index an array, and there are some > situations where BigInts require a different algorithm > (example: http://d.puremagic.com/issues/show_bug.cgi?id=7102 ). > So I am not asking > BigInt to be a drop-in replacement for int in all cases. Despite this code is currently not accepted: BigInt x; byte c = x & 0x7F; Refusing this too introduces another useless difference between ints and BigInts: void main() { BigInt b = true; } Introducing differences between the two types is acceptable if it's required by the semantic difference between the two types, or if it introduces some other improvement. But this is not the case. So this argument of yours is invalid. ------------------------- Derek Parnell: >> In my code such mistakes are uncommon. > But not impossible. Designing an engineering system like a programming language is often a matter of trade-offs. If in my code I find a problem (like integer overflows) quite more common than other ones (like bugs caused by implicit bool->int conversions) it is very right for me to desire the first ones issued first. Priorities are really important in engineering. >> Casts are powerful tools, they shut up the compiler and they assume the >> programmer is perfectly right and has perfect knowledge of what's going >> on. > Do you really believe that the purpose of casts are to "shut up the > compiler"? Seriously? I believe that casts often "shut up the compiler" but I don't belive that's their purpose. One of their main purposes is to offer a standard way to break the static type system in specific points of the program. Every type system restricts the number of the acceptable programs. But programmers sometimes want to write some of those programs. To do this they sometimes use casts. D casts have other secondary purposes, like bit reinterpretation, etc. >> In practice my experience shows that the programmer (me too) sometimes >> doesn't have perfect knowledge (usually because the code later was >> modified, turning the cast into a bug because casts are often silent). > You realize that the exact argument can be made about implicit casts. You are missing something important. Currently this code compiles, it performs a silent implicit cast: bool foo() { return true; } void main() { int x = foo(); } Now you change the code, foo returns a double, the implicit cast stops being accepted and the compiler gives an error: double foo() { return 1.5; } void main() { int x = foo(); } The same doesn't happen if you use an explicit cast. This is the original code if we now require a cast to assign a bool to an int: bool foo() { return true; } void main() { int x = cast(int)foo(); } Now if you modify the code, so foo returns a double, the cast keeps silencing the compiler and this is a possible bug that goes unnoticed (you lose information doing double->int, while bit->int doesn't lose information): double foo() { return 1.5; } void main() { int x = cast(int)foo(); } --------------------- Don: > I think stuff like > int z += x > y; > should ideally require a cast. That's a crazy operation. If D ints/bools change their semantics in that way, then I agree that BigInt should do the same. But until that moment... Bye, bearophile
