D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 730 - broken operator handling of ifloat/idouble/ireal
Summary: broken operator handling of ifloat/idouble/ireal
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: x86 Linux
: P2 normal
Assignee: Walter Bright
URL:
Keywords: accepts-invalid
Depends on:
Blocks:
 
Reported: 2006-12-23 07:13 UTC by Thomas Kühne
Modified: 2014-02-15 13:20 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Thomas Kühne 2006-12-23 07:13:04 UTC
#
# void foo(){
#    ifloat f = 1.0fi;
#    f *= 2.0fi; // illegal but compiles
# }
#

It looks like all arithmetic operators for imaginary types perform
insufficient type checks.

test cases:
http://dstress.kuehne.cn/nocompile/o/opAssign_21_A.d
http://dstress.kuehne.cn/nocompile/o/opAssign_21_B.d
http://dstress.kuehne.cn/nocompile/o/opAssign_21_C.d
Comment 1 Thomas Kühne 2006-12-23 08:30:34 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

d-bugmail@puremagic.com schrieb am 2006-12-23:
> http://d.puremagic.com/issues/show_bug.cgi?id=730

> test cases:
> http://dstress.kuehne.cn/nocompile/o/opAssign_21_A.d
> http://dstress.kuehne.cn/nocompile/o/opAssign_21_B.d
> http://dstress.kuehne.cn/nocompile/o/opAssign_21_C.d

Should have been:
http://dstress.kuehne.cn/nocompile/o/opMulAssign_21_A.d
http://dstress.kuehne.cn/nocompile/o/opMulAssign_21_B.d
http://dstress.kuehne.cn/nocompile/o/opMulAssign_21_C.d


-----BEGIN PGP SIGNATURE-----

iD8DBQFFjT5cLK5blCcjpWoRAtWEAKCOxes9Y4yOPIUHzXdzthB4topa+ACfU6Ho
znTa8F9q1YbtXUaIWPGrmkQ=
=xHSE
-----END PGP SIGNATURE-----

Comment 2 Walter Bright 2007-10-31 04:30:46 UTC
It's not illegal. The mathematical result is 0, which is what is assigned to f.
Comment 3 Don 2007-11-01 02:54:00 UTC
(In reply to comment #2)
> It's not illegal. The mathematical result is 0, which is what is assigned to f.

The imaginary part of the expression is indeed 0. But that involves an implicit cast from double to idouble, which is very hard to justify. The type of (1.0i * 2.0i) is double. It's not even a cdouble.

The current behaviour violates
a *= b  <---> a = a*b, since the latter won't compile.

idouble *= idouble  is a bug in user code, 100% of the time.

(I actually got bitten by this, when I wrote generic dot product code. You can't assume that a = a*a compiles).
Comment 4 Don 2009-10-14 00:07:25 UTC
Fixed in DMD1.048