1.0E0 allowed but not 1.0F0

[stevengj]

Seems like a slight parser inconsistency:

julia> 1.0e0
1.0

julia> 1.0E0
1.0

julia> 1.0f0
1.0f0

julia> 1.0F0
ERROR: UndefVarError: F0 not defined

(Introduced in #1535.)

[stevengj]

For reference, C/C++ allows either case, but in that language f is strictly a suffix (e.g. you would write 1.0e0f). Fortran uses 1.0e0 and 1.0d0 (any case) for single and double precision. Perhaps unsurprisingly, Julia's syntax is more similar to Lisp and Scheme, which allows either case (and adds s for half precision and l for extended precision), although Lisp uses d instead of e for double precision, with e denoting whatever is "default".

[ararslan]

Allowing this would technically be a breaking change, since it means float literal juxtaposition with a variable called F0 will mean something different. So before we would be able to introduce that syntax, wouldn't we need to deprecate <literal>F0?

[stevengj]

Yeah, we'd have to deprecate <literal>F[+-0123456789]. PITA.

[ararslan]

An easier alternative that would also provide consistency is to go in the other direction: deprecate E in favor of e. Then everything is lowercase and the deprecation is both easier and less annoying to deal with.

[stevengj]

parse(Float64, x) should probably continue to be case insensitive, for reading data produced in other languages. In fact, we could make float parsing more permissive, while making Julia parsing less permissive.

[stevengj]

Currently, parse(Float32, s) is less permissive than Julia:

julia> parse(Float32, "1.0f0")
ERROR: ArgumentError: cannot parse "1.0f0" as Float32
Stacktrace:
 [1] parse(::Type{Float32}, ::String) at ./parse.jl:201

[ararslan]

It looks like that's because we do number parsing in C, and the Float32 parsing function, jl_strtof_c, just casts the result of jl_strtod_c to a float. Unsurprisingly, jl_strtod_c isn't set up to accept f/F, just e/E, which is why that fails.

Edit: That's on Windows. On other systems, we use the built-in strtof_l, which calls strtod_l, which also does not parse f.

[vtjnash]

ref #5690

[Keno]

Bump on this. @JeffBezanson feels strongly that E needs to be supported, but doesn't care about F or consistency for consistency's sake. @StefanKarpinski and I were fine with removing support for E. Other people may feel different. Please discuss.

[ararslan]

+1 for removing E but I don't care that much. -1 for adding F.

[StefanKarpinski]

See also #11212

[bramtayl]

I wonder if it would be possible to solve it in a more general way similar to string literals, such that 10e6 parses as @e_num 10 6 and 0xFF001122 parses as @x_num 0 FF001122. Or something.

[JeffBezanson]

I think it's more trouble than it's worth to do anything here.