<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;">I understand you don't like to rely on the name of your enum cases in you code and that's fine, you can still work with them as is, you won't have to change the way you work just because you don't like the proposal but that doesn't mean everybody has the same opinion you do. But perhaps then instead of enums we should go back to using simple constants because that's exactly what enum cases become if their names are not how you're expected to reference, store and retrieve their values (yes, I understand there are other benefits to using enums instead of constants but that's just how you're using them).<br><br>L</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:brent@architechies.com">Brent Royal-Gordon</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;">02/06/2016 01:40 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:me@lmpessoa.com">Leonardo Pessoa</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:svabox@gmail.com">Vladimir.S</a>; <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] Working with enums by name</span><br><br></div>> Brent, for needing "both Int and Double values" there is a proposal to add tuples instead of the current raw values or allowing assessor properties per case, you should check those out. Perhaps this could also be used to cryptoghaphically sign a raw value but I'm not sure.<br><br>I know; I was the one who suggested accessors.<br><br>> As for working with enum values by name a few examples have already been posted in today but I've done a lot more research in the subject along the day and found there is a correlation between enums and nominal level values in statistics; we cannot test them for a particular order (this could also be interesting for statistic apps but it's another case) and no math with them is valid. So, e.g., the result of the following operation on the planets enum is nonsense:<br>> <br>> | let planet = Planet(rawValue: Planet.Mars.rawValue - Planet.Mercury.rawValue)<br>> <br>> The result will be different if the enum values are zero based than if not. Also any change in list order or the base index or add a new element to the middle of the list will break your intended code if you're storing the raw value in a database. And we know these changes happen.<br><br>All of this is true. And all of this is an argument that *you're using raw values wrong*.<br><br>Raw values are a serialization mechanism. You might be serializing merely within your process, or you might be writing out to disk, through IPC, or across the network, but in all cases you are serializing. You should not be doing arithmetic with a serialized representation (unless that arithmetic is a part of the serialization process, like an error-correcting code you're applying to it). You should not be sorting serialized representations. You should be either communicating the raw value or recreating the instance with it—nothing else.<br><br>In other words, all of these are arguments for putting the order of the Planet in a separate property rather than in the `rawValue`. This would free up the `rawValue` to be a `String` containing the case name. This is not an argument for having both an Int `rawValue` and a String `caseName`; this is an argument for having both a String `rawValue` and an Int property.<br><br> enum Planet: String {<br> accessor var order: Int<br> <br> case mercury { order = 0 }<br> case venus { order = 1 }<br> ...etc...<br> }<br><br>(Want it to be automatic? One could imagine having a compiler substitution for "the index of this case" which could be used as the default value for an accessor:<br><br> enum Planet: String {<br> accessor var order: Int = #caseIndex<br> case mercury, venus, ...<br> }<br><br>Or let you choose a base:<br><br> enum Planet: String {<br> accessor var order: Int = #caseOrder(from: 1)<br> case mercury, venus, ...<br> }<br><br>Or the `ValuesEnumerable` proposal would give you a convenient, though slightly slow, way to do two-way lookup by order:<br><br> enum Planet: String, ValuesEnumerable {<br> var order: Int {<br> return Planet.allValues.index(of: self)!<br> }<br> init(order: Int) {<br> self = Planet.allValues[order]<br> }<br> case mercury, venus, …<br> }<br><br>In short, there are several plausible mechanisms to automate assignment of these numbers, should you want to do that.)<br><br>> Actually, given this characteristic of nominal types (statistic), we should vow to removing init(rawValue:) completely from the language.<br><br>That doesn't follow. The fact that changing something would break code doesn't mean that thing should be removed; it means you should be cautious about changing that thing. If you rename a case, its name changes; does that mean we shouldn't have case name lookups either? Changing any identifier could break something; maybe we should abolish all identifiers from Swift?<br><br>> The real value you're working with in enums is the enum case name not any associated values. By working with the name you're safe should any associated value change, should their order change, you'll only break your app if the case is removed/renamed (with the raw value, you risk having the wrong treatment being given should another enum case takes the value of a removed one).<br><br>RawRepresentable is a serialization mechanism, so *of course* changing the raw value can break serialization. This is true whether you're using `Int` raw values or `String` raw values; it's just that `Int`s are a little easier to change.<br><br>If you create an enum with raw values, the raw values are more or less part of that enum's contract. You shouldn't expect things to continue to work properly if you change them, any more than you should expect them to continue to work properly if you delete a case. In fact, the library resilience document specifically calls out changing raw values as a "binary-compatible source-breaking change": <https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums><br><br>> I agree there are lots of important and more difficult things to review in the language but I wouldn't be wasting my time here if I didn't think this was equally important.<br><br>I don't see how it's particularly important to solve this bizarre corner case of needing both a non-String raw value *and* a way to look up cases by name, particularly since you *still* have not provided a decent example where the non-String rawValue ought to be a rawValue at all.<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br></body></html>