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

[Rien]

Maybe I am missing something, but is this what you want?

class Size {
   let width: Double
   let height: Double
   init(width: Double, height: Double) { … }
}

enum Format {
	case SMALL
	case MEDIUM
        case LARGE
	var size: Size {
             switch self {
                   case SMALL: return Size(width: 100, height: 100)
                   case MEDIUM: …
                   ….
             }
        }
}

let format = Format.SMALL
let width = format.size.width

format.size.width = 50 // error, immutable



> On 10 Oct 2016, at 14:35, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Is this what you're trying to achieve, only using a nicer syntax to represent it?
> http://swiftlang.ng.bluemix.net/#/repl/57fb8ac27365890cc848f831
> 
> 
> On Mon, 10 Oct 2016 at 13:04 Mateusz Malczak <mateusz at malczak.info> wrote:
> I think, I have used quite unfortunate naming, which is a root of an
> misunderstanding here. By saying 'enums with stored properties' what I
> was really thinking about, was enumeration type with stored constant,
> immutable properties (constants). I don't want to duplicate 'struct'
> type here, but instead I would like to make it possible to store a
> const values in enumeration cases. So going back to my example once
> again:
> 
> Lest define an enumeration type `Format` with 3 possible cases. Each
> case will be able to carry over some additional information - in this
> case a pair of numbers (but in fact Any? should be possible)
> 
> 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
>     }
> }
> 
> I'm not sure about 'var' clause in that example as it causes all the confusion.
> 
> I can access additional info stored in enum case, but it cannot be
> modified. Format.SMALL doesn't change, as well as non of its
> properties.
> 
> // allowed usage
> let format = Format.SMALL
> let width = format.width // this would be equal to 30 (const value
> assigned to 'width' property on enum case .SMALL)
> 
> // not allowed usage
> let format = Format.SMALL
> format.width = 40 // error, stored values are immutable and can not be modified
> 
> We get all advantages of enumeration type, and, assuming all cases are
> describing the same possible state, we can store some extra
> information in each case. This can be called a third enumeration type
> feature, right next to associated values and rawType.
> 
> --
> | Mateusz Malczak
> 
> 
> 2016-10-10 13:40 GMT+02:00 Jay Abbott <jay at abbott.me.uk>:
> > Thanks for the explanation Mateusz, I think I understand. So the enum still
> > only has 3 cases, SMALL, MEDIUM, and LARGE, but an instance also has some
> > properties?
> >
> > So some code to use it might be:
> > var aFormat = Format.LARGE
> > aFormat.width = 150 // aFormat is still Format.LARGE - this doesn't change
> >
> > Is that right?
> >
> > On Mon, 10 Oct 2016 at 09:06 Mateusz Malczak via swift-evolution
> > <swift-evolution at swift.org> wrote:
> >>
> >> Hi,
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >>
> >> That may look ugly, but can be very useful, if only you think
> >> rawValue's are useful then you should also agree that stored
> >> properties would be useful :)
> >>
> >> --
> >> | Mateusz Malczak
> >>
> >>
> >> 2016-10-10 9:26 GMT+02:00 David Hart via swift-evolution
> >> <swift-evolution at swift.org>:
> >> > Perhaps it is a bit ugly, but I don’t know if allowing stored properties
> >> > on
> >> > enums is the solution: that looks very ugly to me too.
> >> >
> >> > On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution
> >> > <swift-evolution at swift.org> wrote:
> >> >
> >> > I would love to be able to have stored properties in addition to the
> >> > varying
> >> > elements.
> >> >
> >> > Now, I end up creating a secondary struct T and doing case a(T,
> >> > whatever),
> >> > b(T, whatever), c(T, whatever), etc. where the same associated structure
> >> > is
> >> > every case, *or* I end up putting the enum into a struct which means the
> >> > guiding semantics are the struct and not the enumeration. Both
> >> > approaches
> >> > are ugly.
> >> >
> >> > -- E
> >> >
> >> > On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution
> >> > <swift-evolution at swift.org> wrote:
> >> >
> >> > 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)
> >> >>   }
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution