## digitalmars.D.learn - What's the rationale for considering "0x1.max" as invalid ?

• Basile B. (4/4) Apr 05 2016 0x1.max // exponent expected in hex float
• Basile B. (2/6) Apr 05 2016 https://issues.dlang.org/show_bug.cgi?id=15880
• Alex Parrill (4/8) Apr 05 2016 It's potentially ambiguous with hexadecimal floating point numbers
• Basile B. (9/19) Apr 05 2016 Yes but it's pointless to allow the decimal separator to be
• Basile B. (9/31) Apr 05 2016 I mean that the rule could be: the decimal separator must be
• Alex Parrill (6/39) Apr 06 2016 Looks like that's how it works for decimal floats; I.e. 1.e5 is
Basile B. <b2.temp gmx.com> writes:
```0x1.max // exponent expected in hex float
0x1 .max // OK
1.max // OK

What's the ambiguity when it's an hex literal ?
```
Apr 05 2016
Basile B. <b2.temp gmx.com> writes:
```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 ?

https://issues.dlang.org/show_bug.cgi?id=15880
```
Apr 05 2016
Alex Parrill <initrd.gz gmail.com> writes:
```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
```
Apr 05 2016
Basile B. <b2.temp gmx.com> writes:
```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
}
```
Apr 05 2016
Basile B. <b2.temp gmx.com> writes:
```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
```
Apr 05 2016
Alex Parrill <initrd.gz gmail.com> writes:
```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.
```
Apr 06 2016