• H. S. Teoh (25/25) Feb 15 2012 What's the original rationale for requiring that hex float literals must
• Don Clugston (2/5) Feb 16 2012 The syntax comes from C99.
• Stewart Gordon (4/9) Feb 16 2012 Do you mean the syntax has just been copied straight from C99 without an...
• Don Clugston (11/21) Feb 16 2012 Yes. There would need to be a good reason to do so.
• Timon Gehr (2/27) Feb 16 2012 static assert(is(typeof(7i)==idouble));
• Don Clugston (2/33) Feb 17 2012 Ooh, that's bad.
• Timon Gehr (4/38) Feb 17 2012 Indeed. But the implementation of complex and imaginary numbers is
• H. S. Teoh (7/17) Feb 17 2012 Hmph. So complex literals are deprecated, right? So I should disable

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

What's the original rationale for requiring that hex float literals must
always have an exponent? For example, 0xFFi obviously must be float, not
integer, so why does the compiler (and the spec) require an exponent?

Also, the specs say:

	FloatLiteral:
		Float
		Float Suffix
		...

	Float:
		DecimalFloat
		HexFloat

	Suffix:
		FloatSuffix
		...

	FloatSuffix:
		f
		F

This is ambiguous, since you could interpret 0xFFp0F as either 0xFFp0
followed by the suffix 'F', or 0xFFp0F with an exponent of 0x0F no
suffix.


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but
I disagree: without wheel reinventers, we would be still be stuck with
wooden horse-cart wheels.

Don Clugston <dac nospam.com> writes:

On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals must
 always have an exponent? For example, 0xFFi obviously must be float, not
 integer, so why does the compiler (and the spec) require an exponent?

The syntax comes from C99.

Stewart Gordon <smjg_1998 yahoo.com> writes:

On 16/02/2012 12:04, Don Clugston wrote:
 On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals must
 always have an exponent? For example, 0xFFi obviously must be float, not
 integer, so why does the compiler (and the spec) require an exponent?

 The syntax comes from C99.

Do you mean the syntax has just been copied straight from C99 without any
thought about 
making it more lenient?

Stewart.

Don Clugston <dac nospam.com> writes:

On 16/02/12 13:28, Stewart Gordon wrote:
 On 16/02/2012 12:04, Don Clugston wrote:
 On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals must
 always have an exponent? For example, 0xFFi obviously must be float, not
 integer, so why does the compiler (and the spec) require an exponent?

 The syntax comes from C99.

 Do you mean the syntax has just been copied straight from C99 without
 any thought about making it more lenient?

 Stewart.

Yes. There would need to be a good reason to do so.

For the case in question, note that mathematically, imaginary integers 
are perfectly valid. Would an imaginary integer literal be an idouble, a 
ifloat, or an ireal? I don't think it could be any:

foor(float x)
foor(double x)
fooi(ifloat x)
fooi(idouble x)

foor(7); //ambiguous, doesn't compile
fooi(7i); // by symmetry, this shouldn't compile either

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/16/2012 05:06 PM, Don Clugston wrote:
 On 16/02/12 13:28, Stewart Gordon wrote:
 On 16/02/2012 12:04, Don Clugston wrote:
 On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals
 must
 always have an exponent? For example, 0xFFi obviously must be float,
 not
 integer, so why does the compiler (and the spec) require an exponent?

 The syntax comes from C99.

 Do you mean the syntax has just been copied straight from C99 without
 any thought about making it more lenient?

 Stewart.

 Yes. There would need to be a good reason to do so.

 For the case in question, note that mathematically, imaginary integers
 are perfectly valid. Would an imaginary integer literal be an idouble, a
 ifloat, or an ireal? I don't think it could be any:

 foor(float x)
 foor(double x)
 fooi(ifloat x)
 fooi(idouble x)

 foor(7); //ambiguous, doesn't compile
 fooi(7i); // by symmetry, this shouldn't compile either

static assert(is(typeof(7i)==idouble));

Don Clugston <dac nospam.com> writes:

On 16/02/12 17:36, Timon Gehr wrote:
 On 02/16/2012 05:06 PM, Don Clugston wrote:
 On 16/02/12 13:28, Stewart Gordon wrote:
 On 16/02/2012 12:04, Don Clugston wrote:
 On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals
 must
 always have an exponent? For example, 0xFFi obviously must be float,
 not
 integer, so why does the compiler (and the spec) require an exponent?

 The syntax comes from C99.

 Do you mean the syntax has just been copied straight from C99 without
 any thought about making it more lenient?

 Stewart.

 Yes. There would need to be a good reason to do so.

 For the case in question, note that mathematically, imaginary integers
 are perfectly valid. Would an imaginary integer literal be an idouble, a
 ifloat, or an ireal? I don't think it could be any:

 foor(float x)
 foor(double x)
 fooi(ifloat x)
 fooi(idouble x)

 foor(7); //ambiguous, doesn't compile
 fooi(7i); // by symmetry, this shouldn't compile either

 static assert(is(typeof(7i)==idouble));

Ooh, that's bad.

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/17/2012 10:45 AM, Don Clugston wrote:
 On 16/02/12 17:36, Timon Gehr wrote:
 On 02/16/2012 05:06 PM, Don Clugston wrote:
 On 16/02/12 13:28, Stewart Gordon wrote:
 On 16/02/2012 12:04, Don Clugston wrote:
 On 15/02/12 22:24, H. S. Teoh wrote:
 What's the original rationale for requiring that hex float literals
 must
 always have an exponent? For example, 0xFFi obviously must be float,
 not
 integer, so why does the compiler (and the spec) require an exponent?

 The syntax comes from C99.

 Do you mean the syntax has just been copied straight from C99 without
 any thought about making it more lenient?

 Stewart.

 Yes. There would need to be a good reason to do so.

 For the case in question, note that mathematically, imaginary integers
 are perfectly valid. Would an imaginary integer literal be an idouble, a
 ifloat, or an ireal? I don't think it could be any:

 foor(float x)
 foor(double x)
 fooi(ifloat x)
 fooi(idouble x)

 foor(7); //ambiguous, doesn't compile
 fooi(7i); // by symmetry, this shouldn't compile either

 static assert(is(typeof(7i)==idouble));

 Ooh, that's bad.

Indeed. But the implementation of complex and imaginary numbers is 
pretty much broken in the front-end anyway. For example, double and 
idouble are type combined to double iirc.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Feb 17, 2012 at 02:41:10PM +0100, Timon Gehr wrote:
 On 02/17/2012 10:45 AM, Don Clugston wrote:
On 16/02/12 17:36, Timon Gehr wrote:


[...]
static assert(is(typeof(7i)==idouble));

Ooh, that's bad.

 
 Indeed. But the implementation of complex and imaginary numbers is
 pretty much broken in the front-end anyway. For example, double and
 idouble are type combined to double iirc.

Hmph. So complex literals are deprecated, right? So I should disable
them in my lexer? I assume Phobos doesn't use them anymore?


T

-- 
Without geometry, life would be pointless. -- VS