On Tuesday, 24 April 2012 at 22:45:37 UTC, Marco Leise wrote:
Am Wed, 25 Apr 2012 06:00:31 +0900
schrieb "Tyro[17]" <[email protected]>:
I believe the following two lines of code should produce the
same output. Is there a specific reason why doesn't allow
this? Of course the only way to store the result would be to
put in into a BigInt variable or convert it to string but I
don't that shouldn't prevent the compiler from producing the
correct value.
(101^^1000).to!string.writeln;
(BigInt(101)^^1000).writeln;
Regards,
Andrew
Well... what do you want to hear? I like to know that the
Honestly, I just want to hear the rationale for why things are
the way they are. I see thing possible in other languages that
I know are not as powerful as D and I get to wonder why... If
I don't understand enough to make a determination on my
own, I simply ask.
result of mathematical operations doesn't change its type
depending on the ability to compile-time evaluate it and the
magnitude of the result. Imagine the mess when the numbers are
replaced by constants that are defined else where. This may
D provides an auto type facility that determins which the type
that can best accommodate a particular value. What prevents
the from determining that the only type that can accommodate
that value is a BigInt? The same way it decides between int,
long, ulong, etc.
work in languages that are not strongly typed, but we rely on
the exact data type of an expression. You are calling a
function called to!string with the overload that takes an int.
Why couldn't to!string be overloaded to take a BigInt?
A BigInt or a string may be handled entirely differently by
to!string. The compiler doesn't know what either BigInt is or
what to!string is supposed to do. It cannot make the assumption
The point is this, currently 2^^31 will produce a negative long
value on my system. Not that the value is wrong, the variable
simply cannot support the magnitude of the result for this
calculation so it wraps around and produces a negative value.
However, 2^^n for n>=32 produces a value of 0. Why not
produce the value and let the user choose what to put it into?
Why not make the he language BigInt aware? What is the
negative effect of taking BigInt out of the library and make it
an official part of the language?
that passing a string to it will work the same way as passing
an int. What you would need is that int and BigInt have the
same semantics everywhere. But once you leave the language by
calling a C function for example you need an explicit 32-bit
int again.
If you need this functionality use a programming language that
has type classes and seamlessly switches between int/BigInt
types, but drops the systems language attribute. You'll find
languages that support unlimited integers and floats without
friction. Or you use BigInt everywhere. Maybe Python or
Mathematica.
I am not interested in another language (maybe in then future),
simply an understanding why things are the way they are.
Andrew
