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]" <nos...@home.com>:
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 is
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 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
