<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">Java enums automatically have a static values() method that return an array with all values in an enum.<br></div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">Vladimir.S via swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">26/05/2016 02:36 PM</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:narrativium+swift@gmail.com">Ross O'Brien</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Cc: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case</span><br><br></div>On 26.05.2016 19:50, Ross O'Brien wrote:<br>> Perhaps there's an argument to be made for a sort of 'enumDictionary' type<br>> - a dictionary whose keys are all the cases of an enum, and is thus<br>> guaranteed to produce a value.<br><br>In Delphi(Pascal) you can define an array with indexes of enum type i.e.:<br>type<br> TMyEnum = (One, Two)<br>var<br> MyVal : array[TMyEnum] of String<br>const<br> MyConsts : array [TMyEnum] of String = ('just one', 'two here')<br> // compiler will check that values for each enum were specified here<br><br>,so you can do<br>var e: TMyEnum<br>e := One;<br>MyVal[e] := 'hello';<br>s2 := MyConsts[e];<br><br>This is really useful and used a lot. And this is safe in meaning compiler <br>will notify you if you changed the enum - you'll have to change such <br>constant array.<br><br>I wish we'll have something like this in Swift.<br><br>><br>> I think the question I have is how you'd access the values, syntactically.<br>> To use the Planet example, if '.earth' is a value of the Planet enum, is<br>> '.earth.mass' an acceptable way to access its mass? Or perhaps<br>> 'Planet[.earth].mass'?<br><br>Just like .rawValue currently, i.e.<br>let e = Planet.earth<br>print(e.mass, e.description)<br><br>><br>> On Thu, May 26, 2016 at 4:43 PM, Vladimir.S via swift-evolution<br>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:<br>><br>> Or(if we are sure we'll don't forget to udpate `infoDict` in case of<br>> new added case in future):<br>><br>> enum Planet {<br>> case earth<br>> case moon<br>><br>> struct PlanetInfo {<br>> var mass: Double<br>> var description: String<br>> }<br>><br>> private static let infoDict = [<br>> Planet.earth :<br>> PlanetInfo(mass: 1.0, description:"Earth is our home"),<br>> .moon:<br>> PlanetInfo(mass: 0.2, description:"Just a moon"),<br>> ]<br>><br>> var info : PlanetInfo { return Planet.infoDict[self]! }<br>> }<br>><br>> But I agree with you, IMO we need static stored properties for each case.<br>><br>><br>> On 26.05.2016 18 <tel:26.05.2016%2018>:15, Jānis Kiršteins wrote:<br>><br>> The problem is that PlanetInfo values are recreated each time while<br>> they are static. Imagine if PlanetInfo where some type that expensive<br>> to create performance wise.<br>><br>> You could solve it by:<br>><br>> enum Planet {<br>> struct PlanetInfo {<br>> var mass: Double<br>> var description: String<br>> }<br>><br>> case earth<br>> case moon<br>><br>> private static earthInfo = PlanetInfo(mass: 1.0, description:<br>> "Earth is our home")<br>> private static moonInfo = PlanetInfo(mass: 0.2, description:<br>> "Just a moon")<br>><br>> var info : PlanetInfo {<br>> switch self {<br>> case earth: return PlanetInfo.earthInfo<br>> case moon: return PlanetInfo.moonInfo<br>> }<br>> }<br>> }<br>><br>> But that again more verbose. The proposed solution is explicit that<br>> those properties are static for each case.<br>><br>><br>> On Thu, May 26, 2016 at 5:58 PM, Vladimir.S via swift-evolution<br>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:<br>><br>> I support the proposal, but couldn't the initial target be<br>> achieved today<br>> with such (more verbose,yes) solution? :<br>><br>> enum Planet {<br>> struct PlanetInfo {<br>> var mass: Double<br>> var description: String<br>> }<br>><br>> case earth<br>> case moon<br>><br>> var info : PlanetInfo {<br>> switch self {<br>> case earth: return PlanetInfo(mass: 1.0,<br>> description: "Earth is<br>> our home")<br>> case moon: return PlanetInfo(mass: 0.2,<br>> description: "Just a<br>> moon")<br>> }<br>> }<br>> }<br>><br>><br>> let e = Planet.earth<br>> print(e, e.info.description)<br>><br>> let m = Planet.moon<br>> print(m, m.info.description)<br>><br>><br>><br>> On 26.05.2016 8:26, Charlie Monroe via swift-evolution wrote:<br>><br>><br>> What this proposal is asking for is an easier way to<br>> have derived values<br>> from enum cases. Asking for more flexible RawValues<br>> means mass and radius<br>> are not derived, they are the source of truth. It goes<br>> against the whole<br>> point of RawRepresentable. You are not saying ‘Mercury<br>> is identified by<br>> the case .mercury’, you are saying ‘Mercury is<br>> identified by a mass of<br>> 3.303e+23’. It’s backwards.<br>><br>><br>><br>> I see what Janis meant in the first email. It's not that<br>> the planet would<br>> be identified by the mass or radius. It could very much be<br>><br>> case Mercury = 1 where (mass: 3, radius: 2),<br>><br>> - Mercury's rawValue would be 1.<br>><br>> The issue here is that sometimes you want additional<br>> information with the<br>> enum. There are many cases where you extend the enum with a<br>> variable:<br>><br>> enum Error {<br>> case NoError<br>> case FileNotFound<br>> ...<br>><br>> var isFatal: Bool {<br>> /// swtich over all values of self goes here.<br>> }<br>><br>> var isNetworkError: Bool {<br>> /// swtich over all values of self goes here.<br>> }<br>><br>> var isIOError: Bool {<br>> /// swtich over all values of self goes here.<br>> }<br>> }<br>><br>> What the propsal suggests is to simplify this to the following:<br>><br>> enum Error {<br>> var isFatal: Bool<br>><br>> case NoError where (isFatal: false, isNetworkError: false,<br>> isIOError:<br>> false)<br>> case FileNotFound where (isFatal: true, isNetworkError:<br>> false, isIOError:<br>> true)<br>> ...<br>><br>> }<br>><br>> So that you assign the additional information to the enum<br>> value itself.<br>><br>> Charlie<br>><br>><br>><br>> On 26 May 2016, at 1:47 PM, David Sweeris via<br>> swift-evolution<br>> <swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org><br>> <mailto:swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org>>> wrote:<br>><br>><br>> On May 25, 2016, at 10:27 PM, Jacob<br>> Bandes-Storch <jtbandes@gmail.com<br>> <mailto:jtbandes@gmail.com><br>> <mailto:jtbandes@gmail.com<br>> <mailto:jtbandes@gmail.com>>> wrote:<br>><br>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris<br>> via swift-evolution<br>> <swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org><br>> <mailto:swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org>>> wrote:<br>><br>> On May 25, 2016, at 7:37 AM, Leonardo<br>> Pessoa via swift-evolution<br>> <swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org><br>> <mailto:swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org>>><br>> wrote:<br>><br>><br>><br>> Hi,<br>><br>> Couldn't this be solved by using<br>> tuples? If not because the syntax<br>> is not allowed I think this would be<br>> more coherent to do it using<br>> current syntax.<br>><br>> enum Planet : (mass: Float, radius:<br>> Float) {<br>> case mercury = (mass: 3.303e+23,<br>> radius: 2.4397e6)<br>> case venus = (mass: 4.869e+24,<br>> radius: 6.0518e6)<br>> case earth = (mass: 5.976e+24,<br>> radius: 6.37814e6)<br>> case mars = (mass: 6.421e+23,<br>> radius: 3.3972e6)<br>> case jupiter = (mass: 1.9e+27,<br>> radius: 7.1492e7)<br>> case saturn = (mass: 5.688e+26,<br>> radius: 6.0268e7)<br>> case uranus = (mass: 8.686e+25,<br>> radius: 2.5559e7)<br>> case neptune = (mass: 1.024e+26,<br>> radius: 2.4746e7)<br>> }<br>><br>><br>><br>> This would be my preferred solution… AFAIK,<br>> the only reason we<br>> can’t do it now is that Swift currently<br>> requires RawValue be an<br>> integer, floating-point value, or string. I<br>> don’t know why the<br>> language has this restriction, so I can’t<br>> comment on how hard it<br>> would be to change.<br>><br>> - Dave Sweeris<br>><br>><br>> Except you'd have to write<br>> Planet.mercury.rawValue.mass, rather than<br>> Planet.mercury.mass.<br>><br>> This could be one or two proposals: allow enums<br>> with tuple RawValues,<br>> and allow `TupleName.caseName.propertyName` to<br>> access a tuple element<br>> without going through .rawValue.<br>><br>><br>><br>> Good point… Has there been a thread on allowing<br>> raw-valued enums to be<br>> treated as constants of type `RawValue` yet? Either<br>> way, removing the<br>> restriction on what types can be a RawValue is<br>> still my preferred<br>> solution.<br>><br>> - Dave Sweeris<br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org><br>> <mailto:swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org>><br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org><br>> <mailto:swift-evolution@swift.org<br>> <mailto:swift-evolution@swift.org>><br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>><br>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org <mailto:swift-evolution@swift.org><br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org <mailto:swift-evolution@swift.org><br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org <mailto:swift-evolution@swift.org><br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></body></html>