Closed MrcSnm closed 2 years ago
Your proposal mentions binary literals, but haxe doesn't have that... so lets also add binary literals to haxe, and add number separators to them as well, and hexdec, please
How useful is this depends on how often people need to write large numbers. I haven't had such needs, but I guess I would just use macros.
e.g.
import Main.LargeNum.*;
class LargeNum {
macro static public function num(str:String) {
var transformed = StringTools.replace(str, ",", "");
return {
expr: EConst(
if (str.indexOf(".") >= 0)
CFloat(transformed)
else
CInt(transformed)
),
pos: haxe.macro.Context.currentPos(),
};
}
}
class Main {
static function main() {
var largeFloat = num("1,000,000.");
$type(largeFloat); //Float
trace(largeFloat); //1000000
var largeFloat = num("1,000,000");
$type(largeFloat); //Int
trace(largeFloat); //1000000
}
}
I believe that needing to import a module, executing a string.replace and modifying the AST is a lot slower than jumping an index when a _
is found within a number. Readability was one of the reasons for this proposal too, having to call a function to do that misses the point
I believe that needing to import a module, executing a string.replace and modifying the AST is a lot slower than jumping an index when a
_
is found within a number. Readability was one of the reasons for this proposal too, having to call a function to do that misses the point
I doubt it will ever have a significant impact on compile time. regardless, you're right about readability. not to mention macros seem to be the default response to language feature requests, even though macros are not very accessible to beginner/intermediate haxe devs
This would be very useful if Haxe had binary literals. But for decimals it doesn't seem so useful. What kind of tasks require a lot of big number literals all over the code base? And by "big" I mean at least six numbers before decimal point. Usually you define such constant in a single place and refer to it by name, not by literal.
I think currently this feature would have a very limited usefulness. So, unless we get binary literals or unless this feature gets widespread in major languages I'd vote against this feature.
unless this feature gets widespread in major languages I'd vote against this feature.
It actually is widespread, to name a few:
This is quite interesting for hex literals, where one could use it to tell the individual bytes apart more easily (in particular for ARGB/RGBA colors).
Usually you define such constant in a single place and refer to it by name, not by literal.
I'd appreciate the constant definition to be number separated, even if it's defined in a single place.
One problem I see is that literal integers are currently 32 bits in Haxe ( I've found the issue! ) and they max up in ten decimal digits. Ten minus seven[^1] equals three, that "looks" limited. So this proposal has more value if number separators are allowed in floats, which major languages do, or in (possible) long integer literals, which major languages also do.
For the binary literals, that would deserve a separate proposal.
[^1] btw, Ruby has _
from its antiquity
I can see this being useful in some instances, but I also kinda hate how it looks...
This proposal has been accepted, see https://haxe.org/blog/evolution-meeting-2021/ for details.
Incredibly useful feature for better code reability, simple to implement, breaks nothing. Rendered version