Don <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #3 from Don <> 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 must be lexed as
56.0, followed by foo.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to