(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.
Comment #5 by code — 2012-06-14T07:36:35Z
(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.
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.
Comment #8 by timon.gehr — 2012-06-21T14:30:47Z
(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;
Comment #9 by code — 2012-06-21T14:34:32Z
(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.
Comment #10 by code — 2012-06-21T14:41:40Z
(In reply to comment #8)
> alias typeof(meter*meter) Area;
> alias typeof(meter*meter*meter) Volume;
> alias typeof(kilogram/(meter*meter*meter)) Density;
For an example of a working design similar to this, see my std.units prototype (there didn't seem to be much interest in it, so I never actually pursued Phobos integration so far):
https://github.com/klickverbot/phobos/blob/units/std/units.dhttp://klickverbot.at/code/units/std_units.html
(the implementation is more ugly than it needs to be because of a number of now-fixed compiler bugs, but that's not the point here)
Note how any template taking a unit type also accepts an alias to a unit struct, thus removing the need to deal with the actual unit types in virtually all situations, which avoids cluttering up the code with typeof() and .init. For example, new compound units are just defined like this:
---
enum newton = kilogram * metre / pow!2(second);
---
Comment #11 by code — 2012-06-21T14:46:24Z
(In reply to comment #8)
> (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.
I think this would be opening a very big can of worms, because is(typeof(…)) has been equivalent to __traits(compiles, …) so far (well, for things that have a type).
Comment #12 by timon.gehr — 2012-06-21T16:00:03Z
(In reply to comment #11)
> (In reply to comment #8)
> > (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.
>
> I think this would be opening a very big can of worms, because is(typeof(…))
> has been equivalent to __traits(compiles, …) so far (well, for things that have
> a type).
I don't think that not conflating the notions of being able to deduce a type for
an expression and of whether or not it actually compiles in a given context is
opening any cans of worms.
What I am suggesting is to make __traits(compiles, ...) behave like is(typeof({ ...;})).
Comment #13 by github-bugzilla — 2013-03-06T22:04:32Z
I'm going to mark this as an enhancement because it changes existing behavior, and that behavior was relied upon, even though arguably it should never have accepted that behavior.