^^ limitation

[Tryo[17]]

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]" <nospam at 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