On 12/10/11 12:11 PM, Walter Bright wrote:
That's because
Matrix!(int, cast(int)1)
is considered a different template instantiation (and hence a different
type) from
Matrix!(int, cast(uint)1)
Instantiation types are based on the arguments' types, not the
parameters' types.
Which is, in my not-so-humble opinion, just plain broken. Template value
parameters are, well, values, and there is no way there can ever be a
difference between whether a value of an integral type represents 1 or 1u.
This is a long-standing bug, and makes unsigned template value
parameters and, to a lesser extent, integral template value parameters
in general virtually unusable, because you hit hard-to-debug issues with
confusing error messages all over the place.
It gets even worse once CTFE comes into play (or compile-time values in
general, as opposed to directly passing number literals) for two
reasons: First, the error messages become totally useless, that is
something similar to »Foo!(n) can't be implicitly converted to Foo!(n)«.
Second, even if you litter your code with explicit casts all over the
place, it is not really possible to get it to behave like intended
because of what I presume constant-folding issues.
I know this first hand, because I worked on a units-of-measurement
library which relies on units being uniquely represented as types
because the unit type becomes part of the type of quantities as a
template parameter (I presented it at the NG a while back, by the way:
http://www.digitalmars.com/d/archives/digitalmars/D/RFC_Units_of_measurement_for_D_Phobos_134590.html).
For derived units (e.g. kg m/s^2), you need compile time rational
arithmetic, which was really hard to get to work because of the issue
discussed here (I don't even remember all the details). But even with my
own unit tests passing, I once in a while get a message saying something
like: Hey, I checked out your units library prototype, and while it
works nice for most cases, I encountered this situation where … [some
situation in which 1 != 1 for DMD]. I tried really hard to work around
this, but I couldn't find a reliable solution.
Also, I'd like to note that I am not alone with this opinion; Don,
Kenji, Jonathan among others agree that the current behavior is
confusing. A few reports of this issue (and related ones):
http://d.puremagic.com/issues/show_bug.cgi?id=3467
http://d.puremagic.com/issues/show_bug.cgi?id=2257
http://d.puremagic.com/issues/show_bug.cgi?id=2550
Kenji even came up with a fix in form of a pull request, which you
turned down without explanation:
https://github.com/D-Programming-Language/dmd/pull/449
So, could you please at least elaborate why you think the current
behavior is correct, and what advantages it has to outweigh the massive
confusion it causes?
Thanks,
David
