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

[Mateusz Malczak]

Hi Jay,

> 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.
I think its more about the way you see enumeration type. In most cases
enum cases just carry over some information. When you need to get that
additional
information you will use switch or rawValue. On one hand we currently
do have an enums with associated values, where you can attach
different values with single enum case. On the other hand we do have
enums with rawType where you can already store some information in
enum cases. Having possibility to store properties would just be an
extension to the rawType case.

> What could you do with this special enum - what would the code that
> uses it look like?
I don't see it as special type of enums, its more or less the same
case as accessing rawValue property (please look at my examples in
initial mail). You can think of them as enums that are able carry over
some more information than only a RawType value.

Let me once again share a code from initial proposal email :
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
    }
}

In that example you have an enum carrying over some extra informations.

regards
--
| Mateusz Malczak


2016-10-10 2:03 GMT+02:00 Jay Abbott <jay at abbott.me.uk>:
> 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