Daniel Keep wrote:
Charles Hixson wrote:
Suppose that you have four types, equivalent to, say, float.
Call one of them Horiz, one Vertic, one Radians, and one Radius.
These are all floats, but when you specify, say,
float dist (Horiz x, Vert y)
{ return sqrt(x * x + y * y); }
It's important that the arguments aren't Radius and Radians. Or Horiz
and Horiz.
[snip]
There's no problem with that: make them structs that implement the
appropriate operators.
See, what I don't get (note: this is how I perceive it) is the desire to
have this sort of type protection, but require the compiler to somehow
be psychic in order to know when and where you don't care and throw it away.
You either have distinct types that aren't automatically compatible, or
you don't.
-- Daniel
No such requirement. If it's based on a type, then it can be used as
that type. But the converse shouldn't be true. I.e., in the example it
should require extra effort to use a float where a Horiz was requested.
(Cast would reasonably be required here.) But to use a Horiz as a
float should be trivial.
Actually, typedef almost works for this. The problem is that if, e.g.,
one defines
typedef uint MyType;
and then does
writef (MyType);
the compiler asks whether I mean to use a byte or a ulong. It doesn't
automatically realize that the appropriate type is uint.
(Again, this is D2.023 on Linux.)
