<div dir="ltr"><div>This might open a larger can of worms than I imagine, but what do you folks think about using the `rawValue` of an enum when that rawValue is a fit for the expected type?</div><div><br></div><div>Use case.</div><div><br></div><div>I&#39;m making an animation facade, and it has some speed presets:</div><div><br></div><div>class Animate { </div><div>  enum transitionSpeed: NSTimeInterval {</div><div>    case fast = 0.15</div><div>    case slow = 0.5</div><div>  }</div><div>  enum ambientAnimationSpeed: NSTimeInterval {</div><div>    case fast = 1.0</div><div>    case slow = 5.0</div><div>  }</div><div>  ...</div><div>}</div><div><br></div><div>I did them with static variables at first but that made the call site verbose. Compare:</div><div><br></div><div>Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)</div><div>Animate.fadeIn(view, withSpeed: .fast)</div><div><br></div><div>So, I like the enum approach better, but my library code has to use `rawValue` to do anything with the actual value, of course:</div><div><br></div><div>static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed = .fast) {</div><div>  ...</div><div>  UIView.animateWithDuration(duration.rawValue, animations: { })</div><div>}</div><div><br></div><div>It&#39;s not a serious issue, but the code is more clear and beautiful if it has just myIntent, rather than myIntent.rawValue.</div><div><br></div><div>I&#39;ve hit this issue when modeling other things, such as:</div><div><br></div><div>* server fault codes</div><div>* HTTP status codes</div><div>* Currency codes</div><div>* Days of the week</div><div><br></div><div>Would it be appropriate to &quot;autocast&quot; to the rawValue of the enum when the rawValue&#39;s Type matches the type expectation of the API? Or would this introduce a bunch of type system uncertainty?</div><div><br></div><div>Maybe this could be implemented as a protocol? It feels almost like the convenience of `CustomStringConvertible`&#39;s `description` property.</div></div>