^^ limitation

[James Miller]

On Friday, 27 April 2012 at 00:56:13 UTC, Tryo[17] wrote:
>
> 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.
Because the compiler doesn't know how to make a BigInt, BigInt is 
part of the library, not the language.
>
> Why couldn't to!string be overloaded to take a BigInt?
It is, its the same overload that takes other objects.
>
> 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?

Because this is a native language. The idea is to be close to the 
hardware, and that means fixed-sized integers, fixed-sized floats 
and having to live with that. Making BigInt part of the language 
opens up the door for a whole host of other things to become 
"part of the language". While we're at it, why don't we make 
matrices part of the language, and regexes, and we might aswell 
move all that datetime stuff into the language too. Oh and I 
would love to see all the signals stuff in there too.

The reason we don't put everything in the language is because the 
more you put into the language, the harder it is to move. There 
are more than enough bugs in D right now, and adding more 
features into the language means a higher burden for core 
development. There is a trend of trying to move away from tight 
integration into the compiler, and by extension the language. 
Associative arrays are being worked on to make most of the work 
be done in object.d, with the end result being the compiler only 
has to convert T[U] into AA(T, U) and do a similar conversion for 
aa literals. This means that there is no extra fancy work for the 
compiler to do to support AA's

Also, D is designed for efficiency, if I don't want a BigInt, and 
all of the extra memory that comes with, then I would rather have 
an error. I don't want what /should/ be a fast system to slow 
down because I accidentally type 1 << 33 instead of 1 << 23, I 
want an error of some sort.

The real solution here isn't to just blindly allow arbitrary 
features to be "in the language" as it were, but to make it 
easier to integrate library solutions so they feel like part of 
the language.

--
James Miller