<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I personally don't like the Java values() solution. Nor the solution based on dictionary where you need to use ! to unwrap the optionals.<div class=""><br class=""></div><div class="">There are IMHO only two ways to solve this:</div><div class=""><br class=""></div><div class="">1) allow enums with RawValue being object (AnyClass) and make allow case values to be computed. In the Planet case:</div><div class=""><br class=""></div><div class="">enum Planets: Planet {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case Earth = Planet(mass: 1, radius: 2)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div class="">}</div><div class=""><br class=""></div><div class="">The switch would be performed using ===, i.e. it would be allowed to have two cases with the same mass and radius.</div><div class=""><br class=""></div><div class="">This unfortunately faces a lot of issues, including if you have an ObjC class that may returns in all cases a singleton and all cases would have the same value. This could be handled by an assertion at launch.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">2) allow auto-generation of computed variables on enums (partially as I've proposed):</div><div class=""><br class=""></div><div class="">enum Planets {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@auto var mass: Double /// @auto indicates it's auto-generated</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@auto var radius: Double</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/// The enum value is .Earth and has mass and radius properties.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/// All cases would need to declare these and only literals would</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/// be allowed - i.e. numbers + strings.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case Earth where (mass: 1.0, radius: 2.0)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">which would do nothing else than create the following code:</div><div class=""><br class=""></div><div class="">enum Planets {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var mass: Double {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>switch self {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .Earth: return 1.0</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>var radius: Double {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>switch self {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>case .Earth: return 2.0</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>...</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case Earth</div><div class="">}<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 26, 2016, at 10:03 PM, Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div class=""><div class=""><div style="font-family: Calibri,sans-serif; font-size: 11pt;" class="">I get it and think this was really very interesting in Delphi and I wouldn't mind having something like this in Swift. But despite being able to extend associated information through the use of another array we'd still have more verbosity and scattering than with tuples to implement the examples discussed. And we can already have enum dictionaries just not checking automatically if all enum values have been covered. Moreover there is no loss in having both solutions.<br class=""><br class="">I mentioned the values() method also because I miss a way to iterate through all the values on an enum and since it seems we're discussing the entire way to work with enums here it was worth bringing it up.<br class=""><br class=""></div></div><div dir="ltr" class=""><hr class=""><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;" class="">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;" class=""><a href="mailto:svabox@gmail.com" class="">Vladimir.S</a></span><br class=""><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;" class="">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;" class="">26/05/2016 03:06 PM</span><br class=""><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;" class="">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;" class=""><a href="mailto:me@lmpessoa.com" class="">Leonardo Pessoa</a></span><br class=""><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;" class="">Cc: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;" class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution</a></span><br class=""><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;" class="">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;" class="">Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case</span><br class=""><br class=""></div>Yes, this was mentioned in a similar thread in this email list earlier. <br class="">There is even some proposal for such .values() for Swift enums.<br class=""><br class="">But this values() in Java is not the same thing as discussed dictionary <br class="">with *keys* of enum type or Delphi's arrays with *index* of enum type.<br class=""><br class="">Could you write Java's example for array/dictionary of String which <br class="">*index*(or key) will be of enum type? *And* compiler will check that value <br class="">for each enum case is set in case of array of constants like:<br class="">MyConsts : array [TMyEnum] of String = ('just one', 'two here')<br class="">// compiler will always check that value assigned for each case<br class=""><br class=""><br class="">On 26.05.2016 20:58, Leonardo Pessoa wrote:<br class="">> Java enums automatically have a static values() method that return an array<br class="">> with all values in an enum.<br class="">> ---------------------------------------------------------------------------<br class="">> From: Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">> Sent: 26/05/2016 02:36 PM<br class="">> To: Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">mailto:narrativium+swift@gmail.com</a>><br class="">> Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">> Subject: Re: [swift-evolution] [Proposal] Enums with static stored<br class="">> propertiesforeach case<br class="">><br class="">> On 26.05.2016 19:50, Ross O'Brien wrote:<br class="">>> Perhaps there's an argument to be made for a sort of 'enumDictionary' type<br class="">>> - a dictionary whose keys are all the cases of an enum, and is thus<br class="">>> guaranteed to produce a value.<br class="">><br class="">> In Delphi(Pascal) you can define an array with indexes of enum type i.e.:<br class="">> type<br class="">> TMyEnum = (One, Two)<br class="">> var<br class="">> MyVal : array[TMyEnum] of String<br class="">> const<br class="">> MyConsts : array [TMyEnum] of String = ('just one', 'two here')<br class="">> // compiler will check that values for each enum were specified here<br class="">><br class="">> ,so you can do<br class="">> var e: TMyEnum<br class="">> e := One;<br class="">> MyVal[e] := 'hello';<br class="">> s2 := MyConsts[e];<br class="">><br class="">> This is really useful and used a lot. And this is safe in meaning compiler<br class="">> will notify you if you changed the enum - you'll have to change such<br class="">> constant array.<br class="">><br class="">> I wish we'll have something like this in Swift.<br class="">><br class="">>><br class="">>> I think the question I have is how you'd access the values, syntactically.<br class="">>> To use the Planet example, if '.earth' is a value of the Planet enum, is<br class="">>> '.earth.mass' an acceptable way to access its mass? Or perhaps<br class="">>> 'Planet[.earth].mass'?<br class="">><br class="">> Just like .rawValue currently, i.e.<br class="">> let e = Planet.earth<br class="">> print(e.mass, e.description)<br class="">><br class="">>><br class="">>> On Thu, May 26, 2016 at 4:43 PM, Vladimir.S via swift-evolution<br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">>><br class="">>> Or(if we are sure we'll don't forget to udpate `infoDict` in case of<br class="">>> new added case in future):<br class="">>><br class="">>> enum Planet {<br class="">>> case earth<br class="">>> case moon<br class="">>><br class="">>> struct PlanetInfo {<br class="">>> var mass: Double<br class="">>> var description: String<br class="">>> }<br class="">>><br class="">>> private static let infoDict = [<br class="">>> Planet.earth :<br class="">>> PlanetInfo(mass: 1.0, description:"Earth is our home"),<br class="">>> .moon:<br class="">>> PlanetInfo(mass: 0.2, description:"Just a moon"),<br class="">>> ]<br class="">>><br class="">>> var info : PlanetInfo { return Planet.infoDict[self]! }<br class="">>> }<br class="">>><br class="">>> But I agree with you, IMO we need static stored properties for each case.<br class="">>><br class="">>><br class="">>> On 26.05.2016 18 <<a href="tel:26.05.2016%2018" class="">tel:26.05.2016%2018</a>>:15, Jānis Kiršteins wrote:<br class="">>><br class="">>> The problem is that PlanetInfo values are recreated each time while<br class="">>> they are static. Imagine if PlanetInfo where some type that expensive<br class="">>> to create performance wise.<br class="">>><br class="">>> You could solve it by:<br class="">>><br class="">>> enum Planet {<br class="">>> struct PlanetInfo {<br class="">>> var mass: Double<br class="">>> var description: String<br class="">>> }<br class="">>><br class="">>> case earth<br class="">>> case moon<br class="">>><br class="">>> private static earthInfo = PlanetInfo(mass: 1.0, description:<br class="">>> "Earth is our home")<br class="">>> private static moonInfo = PlanetInfo(mass: 0.2, description:<br class="">>> "Just a moon")<br class="">>><br class="">>> var info : PlanetInfo {<br class="">>> switch self {<br class="">>> case earth: return PlanetInfo.earthInfo<br class="">>> case moon: return PlanetInfo.moonInfo<br class="">>> }<br class="">>> }<br class="">>> }<br class="">>><br class="">>> But that again more verbose. The proposed solution is explicit that<br class="">>> those properties are static for each case.<br class="">>><br class="">>><br class="">>> On Thu, May 26, 2016 at 5:58 PM, Vladimir.S via swift-evolution<br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">>><br class="">>> I support the proposal, but couldn't the initial target be<br class="">>> achieved today<br class="">>> with such (more verbose,yes) solution? :<br class="">>><br class="">>> enum Planet {<br class="">>> struct PlanetInfo {<br class="">>> var mass: Double<br class="">>> var description: String<br class="">>> }<br class="">>><br class="">>> case earth<br class="">>> case moon<br class="">>><br class="">>> var info : PlanetInfo {<br class="">>> switch self {<br class="">>> case earth: return PlanetInfo(mass: 1.0,<br class="">>> description: "Earth is<br class="">>> our home")<br class="">>> case moon: return PlanetInfo(mass: 0.2,<br class="">>> description: "Just a<br class="">>> moon")<br class="">>> }<br class="">>> }<br class="">>> }<br class="">>><br class="">>><br class="">>> let e = Planet.earth<br class="">>> print(e, e.info.description)<br class="">>><br class="">>> let m = Planet.moon<br class="">>> print(m, m.info.description)<br class="">>><br class="">>><br class="">>><br class="">>> On 26.05.2016 8:26, Charlie Monroe via swift-evolution wrote:<br class="">>><br class="">>><br class="">>> What this proposal is asking for is an easier way to<br class="">>> have derived values<br class="">>> from enum cases. Asking for more flexible RawValues<br class="">>> means mass and radius<br class="">>> are not derived, they are the source of truth. It goes<br class="">>> against the whole<br class="">>> point of RawRepresentable. You are not saying ‘Mercury<br class="">>> is identified by<br class="">>> the case .mercury’, you are saying ‘Mercury is<br class="">>> identified by a mass of<br class="">>> 3.303e+23’. It’s backwards.<br class="">>><br class="">>><br class="">>><br class="">>> I see what Janis meant in the first email. It's not that<br class="">>> the planet would<br class="">>> be identified by the mass or radius. It could very much be<br class="">>><br class="">>> case Mercury = 1 where (mass: 3, radius: 2),<br class="">>><br class="">>> - Mercury's rawValue would be 1.<br class="">>><br class="">>> The issue here is that sometimes you want additional<br class="">>> information with the<br class="">>> enum. There are many cases where you extend the enum with a<br class="">>> variable:<br class="">>><br class="">>> enum Error {<br class="">>> case NoError<br class="">>> case FileNotFound<br class="">>> ...<br class="">>><br class="">>> var isFatal: Bool {<br class="">>> /// swtich over all values of self goes here.<br class="">>> }<br class="">>><br class="">>> var isNetworkError: Bool {<br class="">>> /// swtich over all values of self goes here.<br class="">>> }<br class="">>><br class="">>> var isIOError: Bool {<br class="">>> /// swtich over all values of self goes here.<br class="">>> }<br class="">>> }<br class="">>><br class="">>> What the propsal suggests is to simplify this to the<br class="">> following:<br class="">>><br class="">>> enum Error {<br class="">>> var isFatal: Bool<br class="">>><br class="">>> case NoError where (isFatal: false, isNetworkError: false,<br class="">>> isIOError:<br class="">>> false)<br class="">>> case FileNotFound where (isFatal: true, isNetworkError:<br class="">>> false, isIOError:<br class="">>> true)<br class="">>> ...<br class="">>><br class="">>> }<br class="">>><br class="">>> So that you assign the additional information to the enum<br class="">>> value itself.<br class="">>><br class="">>> Charlie<br class="">>><br class="">>><br class="">>><br class="">>> On 26 May 2016, at 1:47 PM, David Sweeris via<br class="">>> swift-evolution<br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>>> wrote:<br class="">>><br class="">>><br class="">>> On May 25, 2016, at 10:27 PM, Jacob<br class="">>> Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a><br class="">>> <<a href="mailto:jtbandes@gmail.com" class="">mailto:jtbandes@gmail.com</a>><br class="">>> <<a href="mailto:jtbandes@gmail.com" class="">mailto:jtbandes@gmail.com</a><br class="">>> <<a href="mailto:jtbandes@gmail.com" class="">mailto:jtbandes@gmail.com</a>>>> wrote:<br class="">>><br class="">>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris<br class="">>> via swift-evolution<br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>>> wrote:<br class="">>><br class="">>> On May 25, 2016, at 7:37 AM, Leonardo<br class="">>> Pessoa via swift-evolution<br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>>><br class="">>> wrote:<br class="">>><br class="">>><br class="">>><br class="">>> Hi,<br class="">>><br class="">>> Couldn't this be solved by using<br class="">>> tuples? If not because the syntax<br class="">>> is not allowed I think this would be<br class="">>> more coherent to do it using<br class="">>> current syntax.<br class="">>><br class="">>> enum Planet : (mass: Float, radius:<br class="">>> Float) {<br class="">>> case mercury = (mass: 3.303e+23,<br class="">>> radius: 2.4397e6)<br class="">>> case venus = (mass: 4.869e+24,<br class="">>> radius: 6.0518e6)<br class="">>> case earth = (mass: 5.976e+24,<br class="">>> radius: 6.37814e6)<br class="">>> case mars = (mass: 6.421e+23,<br class="">>> radius: 3.3972e6)<br class="">>> case jupiter = (mass: 1.9e+27,<br class="">>> radius: 7.1492e7)<br class="">>> case saturn = (mass: 5.688e+26,<br class="">>> radius: 6.0268e7)<br class="">>> case uranus = (mass: 8.686e+25,<br class="">>> radius: 2.5559e7)<br class="">>> case neptune = (mass: 1.024e+26,<br class="">>> radius: 2.4746e7)<br class="">>> }<br class="">>><br class="">>><br class="">>><br class="">>> This would be my preferred solution… AFAIK,<br class="">>> the only reason we<br class="">>> can’t do it now is that Swift currently<br class="">>> requires RawValue be an<br class="">>> integer, floating-point value, or string. I<br class="">>> don’t know why the<br class="">>> language has this restriction, so I can’t<br class="">>> comment on how hard it<br class="">>> would be to change.<br class="">>><br class="">>> - Dave Sweeris<br class="">>><br class="">>><br class="">>> Except you'd have to write<br class="">>> Planet.mercury.rawValue.mass, rather than<br class="">>> Planet.mercury.mass.<br class="">>><br class="">>> This could be one or two proposals: allow enums<br class="">>> with tuple RawValues,<br class="">>> and allow `TupleName.caseName.propertyName` to<br class="">>> access a tuple element<br class="">>> without going through .rawValue.<br class="">>><br class="">>><br class="">>><br class="">>> Good point… Has there been a thread on allowing<br class="">>> raw-valued enums to be<br class="">>> treated as constants of type `RawValue` yet? Either<br class="">>> way, removing the<br class="">>> restriction on what types can be a RawValue is<br class="">>> still my preferred<br class="">>> solution.<br class="">>><br class="">>> - Dave Sweeris<br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>><br class="">>><br class="">> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>><br class="">>><br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a><br class="">>> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>><br class="">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>><br class="">>><br class="">>><br class="">>><br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>><br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class="">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">>><br class="">>><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>