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

[Robert Widmann]

I’ve started doing this to try and mimic “Smart Constructors” in Haskell and I think it works quite well.

struct Format {
  enum FormatBacking {
    case SMALL(Int, Int)
    case MEDIUM(Int, Int)
    case LARGE(Int, Int)
  }
  private let unFormat : FormatBacking

  static var Small : Format {
    return Format(unFormat: .SMALL(30, 30))
  }

  static var Medium : Format {
    return Format(unFormat: .MEDIUM(60, 60))
  }

  static var Large : Format {
    return Format(unFormat: .LARGE(120, 120))
  }

  var width : Int {
    switch self.unFormat {
    case let .SMALL(w, _):
      return w
    case let .MEDIUM(w, _):
      return w
    case let .LARGE(w, _):
      return w
    }
  }

  var height : Int {
    switch self.unFormat {
    case let .SMALL(_, h):
      return h
    case let .MEDIUM(_, h):
      return h
    case let .LARGE(_, h):
      return h
    }
  }
}

Yeah, you’re still subject the switching stuff you mentioned before, but I don’t think this is a whole lot of code.  Java’s constants are convenient but they are an oddly structural feature in a particularly nominal language which makes it not scale particularly cleanly.

~Robert Widmann

> On Oct 8, 2016, at 6:50 PM, Mateusz Malczak via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree, you can achieve similar result using structs (as shown in my
> example 2). But it feels more natural to define it using an
> enumeration type. Enumeration defines a type with well defined set of
> possible values. Sometimes where are additional informations liked
> with enumeration cases (like in example). Using structs for this is
> more like a walk-around because you are using an open type to mimic a
> closed set of possible value. What do you think about that?
> 
> 2016-10-09 0:29 GMT+02:00 Tim Vermeulen <tvermeulen at me.com>:
>> This is precisely what a struct is for, why would you want to be able to do this with enums instead?
>> 
>>> Hi all,
>>> I would like to know you opinion on one feature I feel would be a real 'nice to have' extension to currently available enumeration type. Which is an enumeration type with stored properties. It is sometimes useful to store some extra informations along with enumeration cases. Idea here is to add possibility to define an enumeration type with stored, immutable, properties, defined at compile time for all cases. In opposition to currently available associated values, stored properties should be constant values stored as a part of enumeration case. Proposed feature would be treated as a new feature along the associated values and raw values.
>>> 
>>> Please take a look at an example to illustrate this:
>>> ```swift
>>> enum Format {
>>> case SMALL(30, 30)
>>> case MEDIUM(60, 60)
>>> case LARGE(120, 120)
>>> var width: Double
>>> var height: Double
>>> init(width: Double, height: Double) {
>>> self.width = width
>>> self.height = height
>>> }
>>> }
>>> ```
>>> 
>>> Similar feature is currently available for example in Java (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
>>> 
>>> Currently there are at least tree ways to solve this limitation.
>>> 
>>> 1. use enumeration type with custom struct as a rawValue cons:
>>> a lot of additional code to define structs and implement `ExpressibleByStringLiteral`
>>> not really possible for more complex types, where a complex string parser would be required
>>> 
>>> example:
>>> ```swift
>>> struct FormatStruct: ExpressibleByStringLiteral, Equatable {
>>> var width: Int = 0
>>> var height: Int = 0
>>> public init(width: Int, height: Int) {
>>> self.width = width
>>> self.height = height
>>> }
>>> public init(stringLiteral value: String) {
>>> let set = CharacterSet(charactersIn: "x")
>>> let values = value.components(separatedBy: set)
>>> if let width = Int(values[0]), let height = Int(values[1]) {
>>> self.init(width: width, height: height)
>>> } else {
>>> self.init(width: 0, height: 0)
>>> }
>>> }
>>> init(extendedGraphemeClusterLiteral value: String){
>>> self.init(stringLiteral: value)
>>> }
>>> init(unicodeScalarLiteral value: String) {
>>> self.init(stringLiteral: value)
>>> }
>>> static func ==(lhs: FormatStruct, rhs: FormatStruct) ->Bool {
>>> return (lhs.width == rhs.width)&&(lhs.height == rhs.height)
>>> }
>>> static let A = FormatStruct(width: 30, height: 30)
>>> }
>>> enum Format: FormatStruct {
>>> case SMALL = "30x30"
>>> case MEDIUM = "60x60"
>>> case LARGE = "120x120"
>>> var width: Int {
>>> return rawValue.width
>>> }
>>> var height: Int {
>>> return rawValue.height
>>> }
>>> }
>>> ```
>>> 
>>> 2. static struct values to mimic enumeration type
>>> cons:
>>> enum should be used to define a closed set of possible values
>>> 
>>> example:
>>> ```swift
>>> struct Format: ExpressibleByStringLiteral, Equatable {
>>> var width: Int = 0
>>> var height: Int = 0
>>> public init(width: Int, height: Int) {
>>> self.width = width
>>> self.height = height
>>> }
>>> static let SMALL = FormatStruct(width: 30, height: 30)
>>> static let MEDIUM = FormatStruct(width: 60, height: 60)
>>> static let LARGE = FormatStruct(width: 120, height: 120)
>>> }
>>> ```
>>> 
>>> 3. define enum with getters
>>> cons:
>>> additional, repeated `switch` clauses in getters
>>> 
>>> example:
>>> ```swift
>>> enum Format2 { case SMALL case MEDIUM case LARGE var width: Int { switch self { case .SMALL: return 30 case .MEDIUM: return 60 case .LARGE: return 120 } } var height: Int { switch self { case .SMALL: return 30 case .MEDIUM: return 60 case .LARGE: return 120 } } }
>>> ```
>>> 
>>> What is your opinion on this feature? Or maybe that was not implemented for some reason - if so can I get an few word of explaination what was the motivation for not adding this to the language?
>>> 
>>> best regards
>>> --
>>> | Mateusz Malczak_______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> 
> _______________________________________________
> 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/20161008/75b1c504/attachment.html>