String.toFloat doesn't show decimal if nuls

[nitrajka]

Hello there,

while converting a String to Float I encountered a thing, that shouldn't happen in my opinion. When converting string number without a decimal number or with only zeros as decimal numbers to float, the converted number doesn't need to have at least one decimal. Consider these examples:

String.toFloat "123" == Ok 123 --True
String.toFloat "123.0" == Ok 123 --True
String.toFloat "123" == Ok 123.0 --True
String.toFloat "123.0" == Ok 123.0 --True

The former two seem like an Int to me, not a Float. Shouldn't they have at least one decimal number? 123.0? And because the latter two can be also the result of the same conversion, it seems to be inconsistent.
Try this snippet and open the console. https://ellie-app.com/rM4LtHPchba1

I attach converting from string to float in other languages.

Converting from string to float works this way in Python:

Converting from string to float works this way in Java:

String f = "12";
System.out.println(Float.parseFloat(f)); //12.0

Is this a bug or a feature because Elm is compiled to JS? How is this possible?
Thank you :)

[mostlywhole]

I wouldn't consider it a bug. On its own, the lack of a decimal represents absolute precision or type ambiguity. Thankfully, elm data is always accompanied by a type so we don't have to worry about the second possibility. See what happens when we declare a float in elm-repl.

> a = 123.0
123 : Float

Which means when you try something like this:

a : Float
a = 123

b : Int
b = 123

a == b 

You find yourself looking at this error message

The right side of (==) is causing a type mismatch.

(==) is expecting the right side to be a:

    Float

But the right side is:

    Int

Hint: Elm does not automatically convert between Ints and Floats. Use `toFloat`
and `round` to do specific conversions.
<http://package.elm-lang.org/packages/elm-lang/core/latest/Basics#toFloat>

Hint: With operators like (==) I always check the left side first. If it seems
fine, I assume it is correct and check the right side. So the problem may be in
how the left and right arguments interact.

I agree that appending the decimal to the string conversion could be neat.

a = 123.0 |> toString
"123" : String

But at that point, you could be applying string formatting, which would also give you your desired 0's.

[mostlywhole]

I wouldn't consider it a bug. On its own, the lack of a decimal represents absolute precision or type ambiguity. Thankfully, elm data is always accompanied by a type so we don't have to worry about the second possibility. See what happens when we declare a float in elm-repl.

> a = 123.0
123 : Float

Which means when you try something like this:

a : Float
a = 123

b : Int
b = 123

a == b 

You find yourself looking at this error message

The right side of (==) is causing a type mismatch.

(==) is expecting the right side to be a:

    Float

But the right side is:

    Int

Hint: Elm does not automatically convert between Ints and Floats. Use `toFloat`
and `round` to do specific conversions.
<http://package.elm-lang.org/packages/elm-lang/core/latest/Basics#toFloat>

Hint: With operators like (==) I always check the left side first. If it seems
fine, I assume it is correct and check the right side. So the problem may be in
how the left and right arguments interact.

I agree that appending the decimal to the string conversion could be neat.

a = 123.0 |> toString
"123" : String

But at that point, you could be applying string formatting, which would also give you your desired 0's.