<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;">That caseName I'd the solution I miss and would like to see. Indeed when I see an enum the name is the reference to whatever value it should be holding. Think of this:<br><br>// all relative to Earth's mass, I'm not digging the real values now <br>enum Mass : Float {<br> case Earth = 1.0<br> case Moon = 0.2<br> ...<br>}<br><br>Since the values of each case are what's serialised, should I change the values here to absolute values I'm unable to deserialise the stored values because the values no longer exist.<br><br>IMO enums are a language resource used to mask values by a name just like a group of related constants. Being able to find an enum value by its raw value is a good way to convert the value into an enum but you should not rely on it to ever hold the same value forever so yes enum names are supposed to be the truth but that's just not how it works in Swift (still, I do love being able to parameterise enum cases, so I'm not suggesting to remove them).<br><br>As for having to use rawValue, we could work out a solution that would allow direct use of the properties in the tuple and I already have an idea: to make this:<br><br>enum Mass : Float {<br> case Earth = 1.0<br> case Moon = 0.2<br>}<br><br>be a shortcut in the language that is internally transformed and handled like this by the compiler:<br><br>enum Mass : (rawValue: Float) {<br> case Earth = (rawValue : 1.0)<br> case Moon = (rawValue: 0.2)<br>}<br><br>This doesn't break the current syntax of typed enums and still would allow us to access Planet.mercury.mass (in the previous examples) directly without using rawValue in the middle.<br><br>What do you think?<br><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">Jānis Kiršteins 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:59 AM</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:charlie@charliemonroe.net">Charlie Monroe</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>The argument against giving away raw value is that it grants<br>uniqueness of cases when serialized. One can reliably do:<br><br>// serialize<br>let rawValue = Planet.mercury.rawValue<br><br>// and de-serialize<br>guard let planet = Planet(rawValue: rawValue) else {<br>// ...<br>}<br><br>Currently raw values cannot only be equatables that are also literals<br>so their uniqueness can be checked at compile time. An alternative<br>could be that you can serialize/deserialize by case name. For example:<br><br>// serialize<br>let caseName = Planet.mercury.caseName // "mercury"<br><br>// de-serialize<br>guard let planet = Planet(caseName: "mercury") else {<br>// ...<br>}<br><br>On Thu, May 26, 2016 at 8:26 AM, Charlie Monroe via swift-evolution<br><swift-evolution@swift.org> wrote:<br>> What this proposal is asking for is an easier way to have derived values<br>> from enum cases. Asking for more flexible RawValues means mass and radius<br>> are not derived, they are the source of truth. It goes against the whole<br>> point of RawRepresentable. You are not saying ‘Mercury is identified by the<br>> case .mercury’, you are saying ‘Mercury is identified by a mass of<br>> 3.303e+23’. It’s backwards.<br>><br>><br>> I see what Janis meant in the first email. It's not that the planet would be<br>> 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 information with the<br>> enum. There are many cases where you extend the enum with a 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, isIOError: false)<br>> case FileNotFound where (isFatal: true, isNetworkError: false, isIOError:<br>> true)<br>> ...<br>><br>> }<br>><br>> So that you assign the additional information to the enum value itself.<br>><br>> Charlie<br>><br>><br>><br>> On 26 May 2016, at 1:47 PM, David Sweeris via swift-evolution<br>> <swift-evolution@swift.org> wrote:<br>><br>><br>> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <jtbandes@gmail.com><br>> wrote:<br>><br>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution<br>> <swift-evolution@swift.org> wrote:<br>>><br>>> On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution<br>>> <swift-evolution@swift.org> wrote:<br>>><br>>><br>>> Hi,<br>>><br>>> Couldn't this be solved by using tuples? If not because the syntax is not<br>>> allowed I think this would be more coherent to do it using current syntax.<br>>><br>>> enum Planet : (mass: Float, radius: Float) {<br>>> case mercury = (mass: 3.303e+23, radius: 2.4397e6)<br>>> case venus = (mass: 4.869e+24, radius: 6.0518e6)<br>>> case earth = (mass: 5.976e+24, radius: 6.37814e6)<br>>> case mars = (mass: 6.421e+23, radius: 3.3972e6)<br>>> case jupiter = (mass: 1.9e+27, radius: 7.1492e7)<br>>> case saturn = (mass: 5.688e+26, radius: 6.0268e7)<br>>> case uranus = (mass: 8.686e+25, radius: 2.5559e7)<br>>> case neptune = (mass: 1.024e+26, radius: 2.4746e7)<br>>> }<br>>><br>>><br>>> This would be my preferred solution… AFAIK, the only reason we can’t do it<br>>> now is that Swift currently requires RawValue be an integer, floating-point<br>>> value, or string. I don’t know why the language has this restriction, so I<br>>> can’t comment on how hard it would be to change.<br>>><br>>> - Dave Sweeris<br>><br>><br>> Except you'd have to write Planet.mercury.rawValue.mass, rather than<br>> Planet.mercury.mass.<br>><br>> This could be one or two proposals: allow enums with tuple RawValues, and<br>> allow `TupleName.caseName.propertyName` to access a tuple element without<br>> going through .rawValue.<br>><br>><br>> Good point… Has there been a thread on allowing raw-valued enums to be<br>> treated as constants of type `RawValue` yet? Either way, removing the<br>> restriction on what types can be a RawValue is still my preferred solution.<br>><br>> - Dave Sweeris<br>> _______________________________________________<br>> swift-evolution mailing list<br>> 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>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> 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<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></body></html>