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: -------

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: -------

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: -------

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: -------

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: -------