HaxeFoundation / haxe-evolution

Repository for maintaining proposal for changes to the Haxe programming language
111 stars 58 forks source link

Number Separator #90

Closed MrcSnm closed 2 years ago

MrcSnm commented 2 years ago

Incredibly useful feature for better code reability, simple to implement, breaks nothing. Rendered version

Geokureli commented 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

andyli commented 2 years ago

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
    }
}
MrcSnm commented 2 years ago

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

Geokureli commented 2 years ago

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

RealyUniqueName commented 2 years ago

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.

Gama11 commented 2 years ago

unless this feature gets widespread in major languages I'd vote against this feature.

It actually is widespread, to name a few:

back2dos commented 2 years ago

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).

kaikoga commented 2 years ago

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

Simn commented 2 years ago

I can see this being useful in some instances, but I also kinda hate how it looks...

Simn commented 2 years ago

This proposal has been accepted, see https://haxe.org/blog/evolution-meeting-2021/ for details.