Bug 6277 – Disallow short floating point literals

This comes from bug 3837 and bug 2656 I suggest to turn floating point literals like the following into syntax errors, because the saving of one digit is not worth the troubles they cause: .5 3. And require something like: 0.5 3.0 See also the thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030 Daniel Murphy suggests to allow 1.f and 1.L but this a special case.

1.f will conflict with the UFCS, if it ever gets implemented.

If this idea gets accepted then I think it's worth changing the other direction too, I mean the default printing of a floating point value with no decimal part: import std.stdio; void main() { double x = 3.0; writeln(x); } Currently (2.054beta3. I'd like beta releases to show a progressive beta number too) this prints: 3 Python here prints 3.0 and I think D is better to do the same, especially if the leading zero becomes required for the FP literals.

The proposal is for hex floating point literals too. Daniel Murphy suggests to disallow 1._3 too, to help UFCS (Numeric literals cannot *start* with an underscore already).

Steven Schveighoffer reminds this is probably OK (this compiles with DMD 2.054): void main() { auto x = 1f; static assert(is(typeof(x) == float)); }

1.f is now illegal as a floating point literal (it's considered to be considered using UFCS). I see no reason to continue to allow .1 or 1.0.

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/735c2adbda773f8bf6a8ec6bfefe908ab366849e Changes required for issue# 6277. https://github.com/D-Programming-Language/phobos/commit/17ba4bb5940d579a7306afbfb1d4f26f424fa0aa Merge pull request #708 from jmdavis/6277 Changes required for issue# 6277.

(In reply to comment #7) > https://github.com/D-Programming-Language/dmd/pull/1061 Thank you Jonathan. Pull 1061 implements half of this request: it disallow "5." and it doesn't disallow ".5" Another broken symmetry :-) Is code like this nice looking? In this array one dot is missing by mistake: void main() { double[] a = [.1,.2,.3,.4,.5,6,.7,.8,.9,.10,.11,.12,.13,.14]; } And in D the leading dot syntax is already used to search in the outer scope: int x = 5; void main() { int x = 10; int y = .x; assert(y == 5); }

> Pull 1061 implements half of this request: it disallow "5." and it doesn't > disallow ".5" Given the fact that when writing by hand, .5 wouldn't have a 0 on it and the fact that dmd's tests use that syntax heavily, it just didn't seem reasonable to me to force it to be 0.5. It started looking seriously ugly to me to have have every .9999 be 0.9999 and the like. And the more code that would have to change over a minor thing like that, the more likely Walter would be to reject it anyway. > Is code like this nice looking? In this array one dot is missing by mistake: Then put the 0's in there. There's nothing stopping you from doing that. Besides, the code isn't broken. It compiles just fine and has the same semantics whether you add that decimal point or not. It's just a question of aesthetics. > And in D the leading dot syntax is already used to search in the outer scope: There's no ambiguity there whatsoever, since an identifier can't start with 0.

While I appreciate the rationale here, we need to stop breaking existing code. This is highly annoying and disruptive to existing projects, and I think it's implicated in a lot of abandoned D projects.

(In reply to comment #10) > While I appreciate the rationale here, we need to stop breaking existing code. > This is highly annoying and disruptive to existing projects, and I think it's > implicated in a lot of abandoned D projects. You have introduced UCFS in D, this calls for adaptations in other parts of the language. You can't just introduce UCFS and hope nothing else in D will change. The features of a well designed language must be well adapted to each other.

> While I appreciate the rationale here, we need to stop breaking existing code. > This is highly annoying and disruptive to existing projects, and I think it's > implicated in a lot of abandoned D projects. To be fair, adding UFCS broke code using floating point literals, since 1.f became illegal. My changes would just break anyone who did 1. without a trailing 0, which I would expect to be fairly rare. It's incredibly bizarre IMHO that it was ever allowed (though C has done plenty of other bizarre things). However, it's definitely true that it would have been better to make these changes at the same time that UFCS was introduced so that all of the floating point literal breakage occured at once. So, ideally 1. would definitely be disallowed, and I would expect the impact of a such a change to be minimal, since it's such an unnatural thing to do. I expect that it's been used primarily in lieu of tagging f on the end to make an integer literal into a floating point literal. On the other hand, I'm not sure that I care all that much. It's stupid to allow 1., but I'm never going to use it in my code, and most other people aren't either, so it doesn't really affect me all that much. I'd be much more interested in fighting it if we were talking about introducing the feature rather than it being a legacy from C which we didn't clean up and have had for quite some time. I did find it interesting though that it's actually _easier_ for the lexer to allow trailing decimal points than to disallow them. My first reaction would have been that it would have been harder (due to .. and ...), and a recent discussion on the newsgroup about this shows that several others thought the same. But at least with dmd's implementation (and std.conv.to's implementation as well actually), it's easier to just let there be a trailing decimal point rather than requiring a 0.

(In reply to comment #12) > To be fair, adding UFCS broke code using floating point literals, since 1.f > became illegal. I agree that we do break things now and then as a tradeoff for something else very nice that we want. I don't agree with the rationale that if we broke something here, that means it's fair to break it there, and heck, open season on breaking things. Each breaking change must be considered on its own merits - the advantage accrued vs all the annoyance, irritation, and risk of dead D projects it engenders. Please recall all the posted complaints about D being "unstable". I don't see this change as meeting that bar. After all, it's been around in C forever without making anyone's list I've seen on "things I hate about C".

I think that the irritation caused by this should would be minimal (well disallowing 1. anyway - .1 would get _far_ more complaints), and I'd _like_ to see this change made, but if I'm going to fight over a breaking change, I'd prefer to do so over something that I care about a lot more. > I don't see this change as meeting that bar. After all, it's been around in C > forever without making anyone's list I've seen on "things I hate about C". I expect that that's mostly because it doesn't generally affect people that don't use it, and C has _far_ worse problems. If the complaints that D is getting are generally about small stuff like this, then we're doing something very right, even if we're not doing it perfectly. If we're not going to make the change though, I think that we should close this enhancement request. It seems that we almost always leave them open even when the answer is a definitive no, which makes no sense to me.

(In reply to comment #14) > If we're not going to make the change though, I think that we should close this > enhancement request. There are also 8 votes on this enhancement, so there are 9 or 10 persons that like it. So maybe a small discussion in the D newsgroup is needed before closing this down.

(In reply to comment #13) > After all, it's been around in C > forever without making anyone's list I've seen on "things I hate about C". C doesn't have UCFS. And it's on my list of the things I don't like about C.

>I think that the irritation caused by this should would be minimal Certainly it's easy for the user to fix the code. The *problem*, though, is: "I downloaded this D library and it won't compile! D sux!" "My working D project broke *again*. I'm sick of this. D sux!"

(In reply to comment #17) > Certainly it's easy for the user to fix the code. > > The *problem*, though, is: > > "I downloaded this D library and it won't compile! D sux!" > > "My working D project broke *again*. I'm sick of this. D sux!" Beside using -d (deprecated features) another way to face similar problems is to use an idea from Python, a switch like "-future" that activates features that will be introduced in future (so the -property flag gets moved into "-future" and removed).

I'm as unexcited as Walter about this. It does make sense but the benefits are too small to account for the random breakages. Sorry.

RESOLVED LATER? I didn't even realize that that was an option. I take it that that means that it's something that we'd like to do with a major revision like D3 but don't intend to do with the current version of the language?