[swift-evolution] [Proposal] Enums with stored properties

[Haravikk]

> On 13 Oct 2016, at 09:35, Charles Srstka <cocoadev at charlessoft.com> wrote:
> 
>> On Oct 13, 2016, at 3:34 AM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> 
>>> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On 12 Oct 2016, at 12:31, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> I very much disagree with the proposal, and all of the things supporting it (like deriving enums from other types and whatnot). I think you need to take a step up from caring about whether it’s a struct or enum and think about what you are trying to model; that will guide you towards the correct type(s) to use.
>>>> 
>>>> You have only shown a handful of fixed size values, so I would suggest a computed property in your case:
>>>> 
>>>> enum FixedSize {
>>>>  case small
>>>>  case medium
>>>>  case large
>>>> 
>>>>  struct Size { let width : Int; let height: Int }
>>>> 
>>>>  var size : Size {
>>>>    switch self {
>>>>        case .small: return Size(width: 30, height: 30)
>>>>        // … etc
>>>>    }
>>>>  }
>>>> }
>>>> 
>>>> There is no need for these sizes to be stored at all. If you want them baked in to your enum’s values, clearly you expect them to be specific values. It’s more efficient to just drop the stored data altogether in this case; this enum will get lowered in to single byte, which is more efficient to store and transport.
>>>> 
>>>> Karl
>>> 
>>> Actually this is why I pointed to .rawValue as the solution; you're still using a lot of boiler-plate to implement the computed property via a switch; I don't know how well Swift optimises that, but if it actually runs the switch each time it's not ideal, plus if you have a lot of enum cases then it becomes increasingly burdensome to maintain when the values aren't set alongside the cases themselves.
>>> 
>>> It's certainly one way to do it, but like I said .rawValue enables the size to be set alongside each case, and pulled out much more cleanly, the only problem is that you can't use tuples as a raw value, meanwhile conforming to RawRepresentable can involve a lot more boiler plate overall (though once done it works quite nicely), it's just overkill for any situation where a tuple would do.
>>> 
>>> Again, if we had tuples for raw values we could easily do:
>>> 
>>> enum Format : (width:Int, height:Int) {
>>>     case small = (30, 30)
>>>     case medium = (60, 60)
>>>     case large = (120, 120)
>>> 
>>>     var width:Int { return self.rawValue.width }
>>>     var height:Int { return self.rawValue.height }
>>> }
>> 
>> Raw values are not a general solution, though, since enums with associated types can’t have them.
>> 
>> Charles
> 
> *associated values.

Can anyone clarify why not? This doesn't seem like two things that are mutually exclusive, so the fix there could be allowing raw values on enums with associated values as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161013/92cd1e46/attachment.html>