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

[Jay Abbott]

Mateusz,

To me, "Enumeration defines a type with well defined set of possible
values" seems to contradict the idea of having properties that can have
different values. What could you do with this special enum - what would the
code that uses it look like?



On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
>
> _______________________________________________
> 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/20161010/d4b4b993/attachment.html>