A somewhat little-known feature of C# is the possibility to create implicit or explicit user-defined type conversions.
I have been writing C# code for 6 years now, and I have never used it. So, I’m afraid I might be missing good opportunities.
What are legitimate, good uses of user-defined conversions? Do you have examples where they are better than just defining a custom method?
—
Turns out, Microsoft has some design guidelines about conversions, the most relevant of which is:
Do not provide a conversion operator if such conversion is not clearly
expected by the end users.
But when is a conversion “expected”? Outside of toy number classes, I can’t figure out any real-world use case.
Here’s a summary of the examples provided in the answers:
- Radians/Degrees/double
- Polar/Point2D
- Kelvin/Farenheit/Celsius
The pattern seems to be: implicit conversions are mostly (only?) useful when defining numerical/value types, the conversion being defined by a formula. In retrospect this is kind of obvious. Still, I wonder if non-numerical classes could also benefit from implicit conversions..?
As mentioned in the comments, degrees and rotations are a good example to avoid mixing up double values, especially between APIs.
I pulled out the
RadiansandDegreesclasses we’re currently using and here they are. Taking a look at them now (after so long) I want to clean them up (especially the comments/documentation) and make sure they’re properly tested. Thankfully, I’ve managed to get time in the scheduling to do so. At any rate, use these at your own risk, I can’t guarantee if all the math here is correct as I’m pretty sure we haven’t actually used/tested all the functionality we wrote in.Radians
Degrees
Some sample usage
These really benefit when being used an an API. While, internally, your organization might decide to strictly stick with degrees or radians to avoid mixups, at least with these classes you can use the type that makes the most sense. For example, publicly consumed APIs or GUI APIs can use
Degreeswhereas your heavy math/trig or internal usage might useRadians. Considering the following classes/print function:Yeah, the code is pretty contrived (and terribly ambiguous) but that’s OK! Just goes to show how it can help reduce accidental mixups.
Then they can be really useful for implementing other mathematical concepts based on angles, such as polar coordinates:
Then finally, you could implement a
Point2Dclass (or use the System.Windows.Point) with implicit conversions to/fromPolar:As I said, I want to take another pass at these classes, and probably eliminate the
doubleimplicit conversions toRadiansto avoid a couple corner case mixups and compiler ambiguities that are possible. Those were actually there before we created the staticONE_PI,HALF_PI(and so on) fields and we were converting from some multiple of theMath.PIdouble.EDIT: Here’s the
Polarclass as a demonstration of additional implicit conversions. It takes advantage of theRadiansclass (and thus its implicit conversions) and the helper methods on it and thePoint2Dclass. I haven’t included it here, but thePolarclass can easily implement operators interacting with thePoint2Dclass but those aren’t relevant for this discussion.