> On 13 Oct 2016, at 09:35, Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
>> On Oct 13, 2016, at 3:34 AM, Charles Srstka <cocoa...@charlessoft.com 
>> <mailto:cocoa...@charlessoft.com>> wrote:
>> 
>>> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> On 12 Oct 2016, at 12:31, Karl via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@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?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to