Bug 7652 – Some float literals are now parsed as int.user-property

Not sure of this is wanted or not. 4.f used to be a valid float literal. Since 2.058 the f is mistaken as a user property. Error: no property 'f' for type 'int' It does breaks some code but it's trivial to fix (4.0f), and makes the code more readable too. So I kind of like this "regression".

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.

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.

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

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.

(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'.