What's the rationale for considering "0x1.max" as invalid ?

[Alex Parrill via Digitalmars-d-learn]

On Tuesday, 5 April 2016 at 21:40:59 UTC, Basile B. wrote:
> On Tuesday, 5 April 2016 at 21:10:47 UTC, Basile B. wrote:
>> On Tuesday, 5 April 2016 at 20:56:54 UTC, Alex Parrill wrote:
>>> On Tuesday, 5 April 2016 at 19:00:43 UTC, Basile B. wrote:
>>>> 0x1.max // exponent expected in hex float
>>>> 0x1 .max // OK
>>>> 1.max // OK
>>>>
>>>> What's the ambiguity when it's an hex literal ?
>>>
>>> It's potentially ambiguous with hexadecimal floating point 
>>> numbers
>>>
>>> 0xdeadbeef.p5 // hex float or hex int + method?
>>>
>>> dlang.org/spec/lex.html#HexFloat
>>
>> Yes but it's pointless to allow the decimal separator to be 
>> followed by the exponent:
>>
>> void main()
>> {
>>     import std.stdio;
>>     writeln( typeof(0x1p5).stringof ); // double
>>     writeln( typeof(0x1.p5).stringof ); // double
>> }
>
> I mean that the rule could be: the decimal separator must be 
> followed by a second group of digits. The second group of 
> digits must be followed by an exponent. The first group of 
> digits can be followed by an exponent.
>
> 0x1.0p5 // valid
> 0xp5 // valid
> 0x1.p5 // invalid (p is not a hex digit)
> 0x1.ap5 // valid

Looks like that's how it works for decimal floats; I.e. 1.e5 is 
an int and property lookup, while 1.0e5 is 100000f. Curiously, 1. 
Is 1.0.

I agree that floats should be parsed consistently. For now, you 
can do (0x1).max or typeof(0x1).max.