www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6277] New: Disallow short floating point literals

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277

           Summary: Disallow short floating point literals
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 09 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277


Jacob Carlborg <doob me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




Steven Schveighoffer reminds this is probably OK (this compiles with DMD
2.054):

void main() {
    auto x = 1f;
    static assert(is(typeof(x) == float));
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/735c2adbda773f8bf6a8ec6bfefe908ab366849e


https://github.com/D-Programming-Language/phobos/commit/17ba4bb5940d579a7306afbfb1d4f26f424fa0aa




-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




PDT ---
https://github.com/D-Programming-Language/dmd/pull/1061

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277






 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);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




PDT ---

 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



12:11:46 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




PDT ---

 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




15:05:44 PDT ---


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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277







 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277







 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




15:50:43 PDT ---

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!"

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277






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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com



21:55:49 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |LATER


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6277




PDT ---
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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 23 2012