June 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8220



--- Comment #10 from klickverbot <code@klickverbot.at> 2012-06-21 14:41:40 PDT ---
(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.d http://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);
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8220



--- Comment #11 from klickverbot <code@klickverbot.at> 2012-06-21 14:46:24 PDT ---
(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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8220



--- Comment #12 from timon.gehr@gmx.ch 2012-06-21 16:00:03 PDT ---
(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({
...;})).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 07, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=8220



--- Comment #13 from github-bugzilla@puremagic.com 2013-03-06 22:04:32 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

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

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

[Repost] 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: -------
March 07, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 07, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


--- Comment #14 from Walter Bright <bugzilla@digitalmars.com> 2013-03-06 22:55:42 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2
Next ›   Last »