<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;">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>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. Actually, given this characteristic of nominal types (statistic), we should vow to removing init(rawValue:) completely from the language.<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>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>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;">01/06/2016 06:10 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: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>> This should work but feels like an ugly hack to me. What if I needed<br>> the enum like this?<br>> <br>> | enum Size : Double {<br>> | case Fit = 0.5<br>> | case Fill = 3.0<br>> | }<br><br>What if you needed both Int and Double rawValues? What if you needed rawValues that were cryptographically signed? We have to decide which use cases are common enough to support directly in the language, and I'm not convinced that "I need to look cases up by name, but I have no choice but to use rawValue for something else" is one of them—that is, that it's *so* common that we need to direct our scarce engineering resources towards designing and implementing a separate feature merely to accommodate it. There are a whole lot of things that are *way* higher on our to-do list than this, arguably including metaprogramming features which would let you write this yourself instead of sticking it in the core language.<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br></body></html>