^^ 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 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