On 04/27/2012 03:55 AM, James Miller wrote:
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
s/in D/in the DMD frontend/
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
