Idea: In the next edition, stop accepting `0.` as a valid float literal

What purposes? Making x.0.0 work is entirely orthogonal to this; what else would dropping 1. enable?

2 Likes

The premise here was raised in the original thread, that this would make the parser more flexible and extensible, and remove some ambiguities that could otherwise exist between "integer dot" and "float". My expectation is that an actual RFC proposal to change this syntax would provide concrete examples of such ambiguities in the course of making the case for such a syntax change in a future edition.

But the thing is, would it actually help with making tuple.0.0 work? It doesn't seem like it would, since 0.0 is a lexical float whether or not 0. on its own is.

4 Likes

I think this is a cultural thing. I'm from Denmark and there we always add a trailing 0 to a floating point number. It's not something people ever debate, that's just how we write numbers. (We also use , instead of . but that is not so important).

It was only when I started learning to program that I encountered the US shorthands. Before then it had never occurred to me to remove all trailing or leading zeros from a floating point number.

8 Likes

The zeros being dense, visual noise, is not a cultural thing, I believe. I guess it's just my reading comprehension, I like it when it's clear. (I'm from a country not unlike Denmark.)

1 is easier to read than 1. which is easier to read than 1.0, especially in a dense array or matrix. I prefer the easiest to read of those options, when they are available, for writing numbers.

1 Like

I disagree that 1. is easier to read than 1.0. To me, at least, the . gets quite lost. I think it would be nice if a type inference is {integer} then it should be able to coerce to f32 or f64.

Not a type inference of i32 or u32 mind you (not that those two coerce to each other anyway) but I should be able to do the following:

fn foobar(x: f32);

fn fig_tree() {
    let u = 5;
    foobar(u);
}

I'm sure this differs enormously from person to person. These days I've seen the syntax enough that it feels pretty normal to me — it just didn't feel that way in the beginning.

I still use leading and trailing zeros if I write floating point numbers. I think I like the consistency of how 1.0 has the same format as 1.1.

In my experience, adding implicit widening conversions to numbers (allowing 1 to be treated as 1.0) has been a disaster in every language that tried it.

Many modern languages have dropped this feature, and even relatively simple conversion rules (e. g. like Java's) are considered to be a mistake by its designers.

I'd love to reduce the pointless syntactic variation of writing floating point literals from three variations (123.4, 56., .789) down to one.

I got rid of the 56. variant in Scala, and after dire concerns similar to those voiced here, nobody has an issue with it now.

I could live with a lint though that allowed me to automatically reject the two pointless variations in favor of the real one at least in my code.

Seems like you could get such a lint added to clippy easily.

True. I'd prefer going the language route first.

Unless this would be an edition transitioning lint I would not like to add what would be pedantic or restriction lint in clippy. We generally have a high bar for compiler lints.

Actually, none of the variations are pointless; all three have points ('.').   :laughing:

Just to be clear, I favor such a lint.

4 Likes

Ba-Da-Bump! You'll be here all week!

2 Likes

To clarify something here, with my language team hat on:

  • Whether you consider 1. or 1.0 more readable, we're not going to deprecate the former based solely on preference. At most, that's the domain of a clippy lint, or an allow-by-default rustc lint.

  • The only reason to deprecate 1. would be if doing so eliminated an ambiguity that would enable additional syntax involving an integer followed by a dot followed by some other token. Any proposal regarding the deprecation of 1. would have to come with a clear explanation of the new feature and the grammar ambiguity that would occur otherwise.

So, it's not worth arguing over the readability of one or the other float syntax, until someone comes along with a clear use case and proposal for changing the syntax.

7 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.