http://d.puremagic.com/issues/show_bug.cgi?id=8220

           Summary: invalid function call not detected during semantic
                    analysis
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: timon.gehr@gmx.ch


--- Comment #0 from timon.gehr@gmx.ch 2012-06-11 06:54:29 PDT ---
DMD 2.059:

void foo(int){}
static assert(!__traits(compiles,foo(typeof(0)))); // fail

The static assertion should pass.

-- 
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=8220


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, pull


--- Comment #1 from Kenji Hara <k.hara.pg@gmail.com> 2012-06-11 19:31:20 PDT ---
https://github.com/D-Programming-Language/dmd/pull/1000

-- 
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=8220



--- Comment #2 from github-bugzilla@puremagic.com 2012-06-13 22:59:19 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f20292b8738155431589915166770abd8a2ce82a fix Issue 8220 - invalid function call not detected during semantic analysis

https://github.com/D-Programming-Language/dmd/commit/cb3da3bf9e3f54ec3e89061c99adfd54045fbd80 Merge pull request #1000 from 9rnsr/fix8220

Issue 8220 - invalid function call not detected during semantic analysis

-- 
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=8220



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2012-06-14 00:27:28 PDT ---
Created an attachment (id=1115)
failing test case

-- 
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=8220



--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> 2012-06-14 00:51:28 PDT ---
(In reply to comment #3)
> Created an attachment (id=1115) [details]
> failing test case

I think this test case is not correct code.

(From test case)
> alias typeof(Length*Length) 		Area;
> alias typeof(Length*Area) 		Volume;
> alias typeof(Mass/Volume) 		Density;
> alias typeof(Length*Mass/Time/Time) 	Force;
> alias typeof(1/Time) 			Frequency;
> alias typeof(Force/Area) 		Pressure;
> alias typeof(Force*Length) 		Energy;
> alias typeof(Energy/Time) 		Power;
> alias typeof(Time*Current) 		Charge;
> alias typeof(Power/Current) 		Voltage;
> alias typeof(Charge/Voltage) 		Capacitance;
> alias typeof(Voltage/Current) 		Resistance;
> alias typeof(1/Resistance) 		Conductance;
> alias typeof(Voltage*Time) 		MagneticFlux;
> alias typeof(MagneticFlux/Area) 	MagneticFluxDensity;
> alias typeof(MagneticFlux/Current) 	Inductance;
> alias typeof(Intensity*UnitLess) 	LuminousFlux;
> alias typeof(LuminousFlux/Area) 	Illuminance;

As far as I know, normal expressions cannot take Type as their operands, even if it is defined by operator overloading.

 struct S { void opMul(S s){} }
 S + S;   // this is INVALID code

This rule should be applied even in typeof expression, then
typeof(Length*Length) must be invalid.

-- 
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=8220


klickverbot <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at


--- Comment #5 from klickverbot <code@klickverbot.at> 2012-06-14 07:36:35 PDT ---
(In reply to comment #3)
> Created an attachment (id=1115) [details]
> failing test case

I also think this is genuinely invalid code: Besides the fact that there isn't
really a good reason, grammar-wise, for the code to compile, allowing it as a
special case in typeof() would create exactly the same sort of problems with
is(typeof()) as with __traits(compiles, …) in the original report.

-- 
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=8220



--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> 2012-06-15 09:38:02 PDT ---
Opened identical pull: https://github.com/D-Programming-Language/dmd/pull/1007

-- 
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=8220


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> 2012-06-21 14:16:22 PDT ---
This example has been around a long time, and I've been telling people that that's the way to do it. I'm really reluctant to break it, and there doesn't seem to be an obvious other way to do it.

-- 
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=8220



--- Comment #8 from timon.gehr@gmx.ch 2012-06-21 14:30:47 PDT ---
(In reply to comment #7)
> This example has been around a long time, and I've been telling people that that's the way to do it. I'm really reluctant to break it,

The behaviour must be fixed for __traits(compiles,...), but not necessarily for
typeof.

> and there doesn't seem to be an obvious other way to do it.

alias typeof(Length.init*Length.init)         Area;
alias typeof(Length.init*Area.init)         Volume;
alias typeof(Mass.init/Volume.init)         Density;
...

or even

alias typeof(meter*meter)                       Area;
alias typeof(meter*meter*meter)                 Volume;
alias typeof(kilogram/(meter*meter*meter))      Density;

-- 
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=8220



--- Comment #9 from klickverbot <code@klickverbot.at> 2012-06-21 14:34:32 PDT ---
(In reply to comment #7)
> This example has been around a long time, and I've been telling people that that's the way to do it. I'm really reluctant to break it, and there doesn't seem to be an obvious other way to do it.

Just use typeof(U.init * V.init).

The idea might have seemed nice originally, but I think it has to go the 'bit' route. At least in my opinion, allowing types to be used in place of expressions is one of the most confusing things you can do to the poor programmers out there. I recall stumbling over strange behavior is(typeof(…)) several times in the past, and this might have well been the reason.

What's more, is this interpretation backed by the spec in any way? If not, I can hardly imagine that any alternative frontend would implement typeof() like this.

To restate my point, typeof(<code>) acting differently than just <code> is a
huge source of confusion (constant folding and apparent null pointer
dereferences in typeof() can be bad enough already). There would have to be a
very good excuse not to remove this special case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------