Bug 1335 – typedef-1 can't be stored in same typedef

The following file fails to compile: typedef uint foo; void main() { foo f = 100; f--; // this works foo g = f-1; // this doesn't } ERROR MESSAGE: typedef_problem.d(6): Error: cannot implicitly convert expression (f - 1u) of type uint to foo

that would indicate that the typing rules will only convert back to base types in expressions. (cast(foo)1) + 1 => (cast(uint)(cast(foo)1)) + (cast(uint)1) I think this is the correct way to do things, however an argument might be made for literal being a special case.

This is as intended, but it's still the most annoying thing about typedefs. IMHO typedefs should convert freely to and from their base type, explicit casts should only be needed when converting to other typedefs. Use "foo g = f - cast(foo)1".

Free conversion to and from a typedef might have some issues with overloading of functions. Either the rules have to not apply to function args (a special case) or typdefs become little more than aliases. I agree that having to cast literals to make math work is a bit silly, but I don't known how to fix it without loosing D's advantages over C in this area.

There are a number of ways that you might make this work, but IMHO the current implementation is broken. (Maybe it's working as design, and the design is broken, too, I don't know.) Let me expand the example code: typedef uint foo; void main() { foo f = 100; f--; // this works uint i = f-1; // this works foo g = f-1; // this doesn't } From this example, and by reading the error message, you realize that DMD is allowing implicit conversion typedef->uint, but not the other way around. Isn't this pretty inconsistent? IMHO, implicit conversions either way should be disallowed. We could still allow for nice math with literals if we followed this rule: "Math between numeric typedefs and numeric literals is allowed, and the result has the same type as the typedef." You could even consider allowing math between numeric typedefs and non-typedef variables, but I am more skeptical of that.

> From this example, and by reading the error message, you realize that > DMD is allowing implicit conversion typedef->uint, but not the other > way around. Isn't this pretty inconsistent? this is more or less the same as the class conversion rules conversion towards Object; no cast conversion away from Object; needs cast conversion towards built ins; no cast conversion away from built ins; needs cast typdefs can be considered subsets of what they typedef For the little I've thought of it I'd have no problem with your suggested rule. However, I still want the free down cast.

This is working as designed, so changing it is an enhancement request.

Closing since typedef is effectively deprecated.