[Issue 7652] Some float literals are now parsed as int.user-property
http://d.puremagic.com/issues/show_bug.cgi?id=7652 --- Comment #5 from Don clugd...@yahoo.com.au 2012-05-16 00:48:17 PDT --- (In reply to comment #4) Thank you very much for your explanation. Your hint regarding maximal munch and that only an ending . causes difficulties helped a lot. But 56.foo is lexed as three tokens 56 . foo, isn't it? Yes, because the . isn't followed by a digit. I think the section Floating Literals on http://dlang.org/lex.html does not reflect the current behavior. Because it allows deriving e.g. the decimal float literal 56.f But this should be forbidden. If a . is consumed there must be a digit following. This must be done to abort the matching. Not sure though whether I'm seeing fully. You are correct, it's out of date now. Please open a new bug for that, with keyword 'spec'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7652] Some float literals are now parsed as int.user-property
http://d.puremagic.com/issues/show_bug.cgi?id=7652 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don clugd...@yahoo.com.au 2012-05-15 07:48:47 PDT --- (In reply to comment #2) Out of curiosity I tried (dmd 2.059) how hex floats are affected by the change introduced in 2.058. I.e. I would expect auto = 0xa.p0f; to call @property int p0f(int x); but this does not happen. 0xa.p0f is detected as float literal which makes me think: If 0xa.p0f is lexed as a float literal why was it decided that 1.f should not be lexed as float literal? Or the other way round why is 0xa.p0f not lexed as a property call on an int value. The current behavior is a bit inconsistent. No it isn't. First it tries to parse the number as a float literal (maximal munch). Only if that fails does it try integer. property. Note that with hex float literals, the 'p' plays the role that the '.' plays in a decimal literal. Eg, 0xa.0 is not a valid hex literal, but 0xap7 is. The problem with the decimal literal 1. syntax was that it ends with a . That made UFCS incompatible with maximal munch. eg 56.foo must be lexed as 56.0, followed by foo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7652] Some float literals are now parsed as int.user-property
http://d.puremagic.com/issues/show_bug.cgi?id=7652 --- Comment #4 from jens.k.muel...@gmx.de 2012-05-15 14:59:46 PDT --- Thank you very much for your explanation. Your hint regarding maximal munch and that only an ending . causes difficulties helped a lot. But 56.foo is lexed as three tokens 56 . foo, isn't it? I think the section Floating Literals on http://dlang.org/lex.html does not reflect the current behavior. Because it allows deriving e.g. the decimal float literal 56.f But this should be forbidden. If a . is consumed there must be a digit following. This must be done to abort the matching. Not sure though whether I'm seeing fully. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7652] Some float literals are now parsed as int.user-property
http://d.puremagic.com/issues/show_bug.cgi?id=7652 jens.k.muel...@gmx.de changed: What|Removed |Added CC||jens.k.muel...@gmx.de --- Comment #2 from jens.k.muel...@gmx.de 2012-05-14 05:59:59 PDT --- Out of curiosity I tried (dmd 2.059) how hex floats are affected by the change introduced in 2.058. I.e. I would expect auto = 0xa.p0f; to call @property int p0f(int x); but this does not happen. 0xa.p0f is detected as float literal which makes me think: If 0xa.p0f is lexed as a float literal why was it decided that 1.f should not be lexed as float literal? Or the other way round why is 0xa.p0f not lexed as a property call on an int value. The current behavior is a bit inconsistent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7652] Some float literals are now parsed as int.user-property
http://d.puremagic.com/issues/show_bug.cgi?id=7652 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||WONTFIX --- Comment #1 from Brad Roberts bra...@puremagic.com 2012-03-05 23:41:55 PST --- This was purposeful and documented (though poorly, as: allow 1.userproperty syntax -- I'll get that improved) in the change log for 2.058. Yes it can cause existing code to break. Add the 0. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
