What do you think are good use cases for enum raw values?

Recorded May 22nd 2020 – watch the full episode on YouTube.

‌In your experience, what would be good use cases for enum raw values? Would you use enums for feed information?

Paola Mata: I will often use very simple ones like strengths. It's safer than having to use what they called magic or just free floating magic numbers, or just strings all over your code that you could get wrong, you could mistype. And then it just throws everything off. Or I use them for associated values, any classes that I've defined specifically, like my model classes. I tend to use one.

Sometimes you can use a tuple and have like multiple associated values. You can do that. Or if you can somehow use a value that's just related to your initial associated value, that makes things a little easier as far as comparison.

“If you can somehow use a value that's just related to your initial associated value, that makes things a little easier as far as comparison.”

Paul Hudson: There are lots of reasons I use raw values. I'm not sure why, but one particular one just sprung into my head, when I'm doing, SpriteKit collisions. You want to use doubling of values for your raw value. So one, two, four, eight, 16, 32, and so forth. So you can add them together to see what collided. And you just want both to say CollisionTypes.Building.rawValue and get out 32. So as you say it avoids that magic number of 32 being stuck in your code. It's not always the number behind the scenes, but it lets you refer to it in a more understandable way.

Let's move on and think about places where enums are great fits for stuff. Now if you want to think about two or three places where enums you think should get more use. Where they are really, really applicable to our code and great ideas to fit into there. Where would you say they are and also where are the wrong places?

Paola Mata: As I mentioned before, basically to avoid having to type it in, if you're using an enum with string value. You're avoiding having to write any string value every single time you call them. When you're trying to be for example there's a set, predefined endpoints that you have that you call by a different name.

Maybe it's like this is the speed and this is whatever the endpoint is. When you're trying to be safe and make sure that you don't end up using unintended or just incorrect values anywhere.

“Whenever something new, like CaseIterable comes along, I think like, ‘oh, I've been doing that on my own this whole time.’ And having to have hack myself instead of having it available to me in a very nice protocol.”

Paul Hudson: So would you actually use enums for actual feed information?

Paola Mata: Maybe not enums, but I might add some variables or some functions to get information based on that case.

Paul Hudson: We've seen Swift evolve enums quite a lot over the years. In particular Swift 4.2 added Robert's CaseIterable code. We have Comparable enums landing in Swift 5.3, which as we speak is a month away from entering beta when WWDC starts. And they're wonderful features to have, that really power up enums and make them more useful going forward. Are there still things you think enums are lacking in Swift, and that should be added in future versions?

Paola Mata: I honestly cannot think of any, but I will say that whenever something new, like CaseIterable comes along, I think like, “oh, I've been doing that on my own this whole time.” And having to have hack myself instead of having it available to me in a very nice protocol.

Paul Hudson: You're like, “ah, that's so obvious. I want that straight away.”

“Certainly one thing I value is when you are able to take code, you've been using it a long time. And think actually this is reusable code that anyone could use.”

Paola Mata: Yes. It's obvious. Something I learned about more recently is using fallthrough so that you go through each enum case and take some action. Because something like that allows us more flexibility; it gives us more power with enums.

Paul Hudson: Certainly one thing I value is when you are able to take code you've been using it a long time, and think actually this is reusable code that anyone could use. And Soroush Khanlou gave a wonderful talk on this. He delivered it a number of times, but I saw it in Pragma in Italy three years ago, called You Deserve Nice Things. And it was basically walking through some of his code library of stuff. Here's how to do this. How to do this. And it's simple methods that make Swift collections nicer to use for example.

And things like allSatisfy(), I first saw it there in his code way before it went into Swift 4.2. Things like count(where:), which it was in his talk, I believe, and then he put it into Swift Evolution. It didn't quite make it through for compiler reasons, but it's been accepted and ready to go in the future. And it's a simple thing, like “count how many items have this property.” And of course you can do a filter and account, but it's faster to do it in one run.

So little things that make your life easier, even using your code for a long time to do CaseIterable or whatever it was in your case. Code that everyone else can use is, I think, the genesis of many, many good or great Swift Evolution ideas.

Paola Mata: I tried to look over any currently proposed Swift Evolution specifically for enums, and I didn't see many so that's disappointing. But I think there might've been one or two. I don't know if you're aware of them.

Paul Hudson: So synthesized Comparable enum conformance is 5.3 and that's a pretty nice one. I think they're talking about making frozen enums available to user code, because Frozen is available to Swift internal code but not to us yet. That's possible. Well, I guess that's going to be 5.4 or 5.5 –who knows what in the future?

Sponsor Hacking with Swift and reach the world's largest Swift community!