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@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 <mate...@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 <j...@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@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@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@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@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@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@swift.org > >> > https://lists.swift.org/mailman/listinfo/swift-evolution > >> > > >> > > >> > > >> > _______________________________________________ > >> > swift-evolution mailing list > >> > swift-evolution@swift.org > >> > https://lists.swift.org/mailman/listinfo/swift-evolution > >> > > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org > >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution