[swift-evolution] Could enums have their rawValue type inferred?

[Leonardo Pessoa]

Eric, I think I understood your proposal. If I may explain in other words
it would be "to automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value", am I right? I
think this would imply a little more inference and type checking rules from
the compiler and maybe even take a little longer to fully compile code. I'm
not sure it's feasible but from your examples, I can see how it enhances
readability of the code, so I'm +1 for it. My only concern is that you
would still need to fully declare the enum's name where the value of the
enum is used. Taking from your own example

    Animate.fadeIn(view, withSpeed: .fast)

couldn't be called that way if withSpeed expects and NSTimeInterval because
the compiler won't know whether you're refering to transitionSpeed or to
ambientAnimationSpeed. You would still have to call it like

    Animate.fadeIn(view, withSpeed: transitionSpeed.fast)

even if you had only one possible enum value over all declared enums
because that would still force the compiler to search for each value over
all known enums to define where the value you're using comes from and make
sure there are no two enums with the same value.

Aside from that, I good with the idea.



On 13 May 2016 at 15:09, Eric Miller via swift-evolution <
swift-evolution at swift.org> wrote:

> 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?
>
> Use case.
>
> I'm making an animation facade, and it has some speed presets:
>
> class Animate {
>   enum transitionSpeed: NSTimeInterval {
>     case fast = 0.15
>     case slow = 0.5
>   }
>   enum ambientAnimationSpeed: NSTimeInterval {
>     case fast = 1.0
>     case slow = 5.0
>   }
>   ...
> }
>
> I did them with static variables at first but that made the call site
> verbose. Compare:
>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> Animate.fadeIn(view, withSpeed: .fast)
>
> So, I like the enum approach better, but my library code has to use
> `rawValue` to do anything with the actual value, of course:
>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> .fast) {
>   ...
>   UIView.animateWithDuration(duration.rawValue, animations: { })
> }
>
> It's not a serious issue, but the code is more clear and beautiful if it
> has just myIntent, rather than myIntent.rawValue.
>
> I've hit this issue when modeling other things, such as:
>
> * server fault codes
> * HTTP status codes
> * Currency codes
> * Days of the week
>
> Would it be appropriate to "autocast" to the rawValue of the enum when the
> rawValue's Type matches the type expectation of the API? Or would this
> introduce a bunch of type system uncertainty?
>
> Maybe this could be implemented as a protocol? It feels almost like the
> convenience of `CustomStringConvertible`'s `description` property.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/05a1d4c2/attachment.html>