Peter Baumarchais wrote:However the changes that I am suggesting are not ultimately as complicated as all the other changes that they have been prepared to make.
A quality maths system, with operators, with the option to disable floating point overflow and underflow (for code thats already compiled) is not a particularly greater problem than any of these changes, and is even smaller a change.
First of all, I think you underestimate the complexity of some of your requests in comparison to the features you've mentioned. For instance, writing the enhanced for loop is pretty straightforward, because you only have to tweak the grammar of the language a little bit, and then lift the syntax to regular calls to Iterator
. Overflow checking for types that follow an IEEE standard? Heh.
Secondly, many features you've mentioned were already part of the language from the start. It's much easier to implement a feature using a clean slate than when you have to tack it on an existing language, if there's no straightforward way to lift the syntax. While operator overloading for BigDecimal
may be lifted to calls to add()
etc., the overflow checking for floating point values is new.
Finally, the ease of implementing a feature is not the only factor in deciding whether it will be implemented. The actual formula is more like (chance of implementation) = (community demand) / (difficulty of implementation)
. There was a MUCH greater demand for the advanced for loop, and yes, even the var keyword.
In short, you will probably have to wait for a long time because you're in the minority that really wants this change, especially so if you can't produce scenarios where you absolutely need this behavior.