Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
March 06, 2012 [Issue 7652] Some float literals are now parsed as int.user-property | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=7652 Brad Roberts <braddr@puremagic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |braddr@puremagic.com Resolution| |WONTFIX --- Comment #1 from Brad Roberts <braddr@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: ------- |
May 14, 2012 [Issue 7652] Some float literals are now parsed as int.user-property | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=7652 jens.k.mueller@gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jens.k.mueller@gmx.de --- Comment #2 from jens.k.mueller@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: ------- |
May 15, 2012 [Issue 7652] Some float literals are now parsed as int.user-property | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=7652 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug@yahoo.com.au --- Comment #3 from Don <clugdbug@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: ------- |
May 15, 2012 [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.mueller@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: ------- |
May 16, 2012 [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 <clugdbug@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: ------- |
Copyright © 1999-2021 by the D Language Foundation