Int could very well be an enum, but it would be too verbose because it has billions of possible values, and implementing arithmetic would get tricky.
Bool, on the other hand, is defined to have one of two values and has very limited arithmetic. It’s the perfect candidate for an enum.
Karl
···
On 4 Jul 2016, at 18:55, Anton Zhilin <antonyzhilin@gmail.com> wrote:
2016-07-04 18:34 GMT+03:00 Karl via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
Now that you mention it; why is Bool not an enum?
Looking at the previous discussions, this kind of functionality belongs as part of reflection (once we have a mature reflection API). If you are reflecting a type that is completely known to the compiler (e.g. a concrete value-type, such as a struct or enum), it should be able to statically optimise it.
This is a commonly-enough requested feature that I would like to do it before the reflection API (there’s no public roadmap yet, but I don’t think it’s even under consideration for Swift 4). OTOH, I’m not sure if it makes sense to implement it in hacky way with compiler-generated constants and then replace it once we have a stable ABI.
Probably best to wait for the Swift 4 roadmap discussion and to see what the plans for reflection actually are. So I’m taking back my +1, sorry.
Karl
···
On 5 Jul 2016, at 12:47, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
This is mentioned in Gabriel's proposal:
Implement a native .cases static var for all enumerations without associated values
But as has been mentioned in the discussion, this was mentioned by Brent:
In previous discussions, the core team specifically asked that this be opt-in so that types which don't want it don't need to "pay" for it.