On 07/22/14 18:39, Iain Buclaw via Digitalmars-d wrote: > On 22 July 2014 12:40, Artur Skawina via Digitalmars-d > <[email protected]> wrote: >> On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote: >>> On 21 Jul 2014 22:10, "Artur Skawina via Digitalmars-d" >>> <[email protected] <mailto:[email protected]>> wrote: >>>> For D that is not possible -- if an expression is valid at run-time >>>> then it should be valid at compile-time (and obviously yield the same >>>> value). >>> >>> ...most of the time. >>> >>> CTFE is allowed to do things at an arbitrary precision in mid-flight when >>> evaluating an expression. >> >> That will work for FP, where excess precision is allowed, but will not work >> for integer arithmetic. Consider code which uses hashing and hash-folding >> functions which rely on wrapping arithmetic. If you increase the precision >> then those functions will yield different values. Now a hash value >> calculated at CT is invalid at RT... > > I can still imagine a possibility of such occurring if cross-compiling > from a (doesn't exist) platform at does integer operations at 128bit > to x86, which at runtime is 64bit.
In D integer widths are well defined; exposing the larger range would not be possible. static assert (100_000^^2!=100_000L^^2); [Whether requiring specific integer widths was a good idea or not, redefining them /now/ is obviously not a practical option.] artur
