http://d.puremagic.com/issues/show_bug.cgi?id=4119



--- Comment #2 from bearophile_h...@eml.cc 2010-04-25 04:41:54 PDT ---
Magic numbers are generally to avoid in serious code, it's often better to
define some constants at the top of a function / struct/ class / module, and
use them in the code. This also keeps all them equal if you have to use the
same constant many times in the code.

But multi-precision integers can be useful in little programs too (like 20-50
lines long), where the number literals are often acceptable. A good language
must be able to "scale down" too.

I agree that using a string literal is not very good, multi-precision integral
literals are better, to be able to write a type-safe and clean-looking (or
something similar):

import std.bigint: BigInt;
void main() {
    BigInt i;
    i = 100_000_000_000_000_000_000_000_000_000LL;
}


The usage of a string is a workaround, it's not very nice, but it's easy to
implement, you just need to add this to BigInt (I have added it in my copy of
the BigInt):

void opAssign(T: string)(T x) {
    this = BigInt(x);
}

It's less safe than the multi-precision literal because the string can contain
errors (spaces, etc), but this is true for the BigInt("...") syntax too.

It's also a little less type-safe because the BigInt variable (here 'i') can be
assigned with both an integral value and a string, so you can assign by mistake
it to a unrelated string. But practice with dynamic languages shows that a bit
of type flexibility doesn't burn down programs, it's not a Black Death.
Especially in short programs.

So I think until D gets multi-precision integral literals, the assign to string
is acceptable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to