Usage of the nil coalescing operator is not advanced. You've simply used it in a way that makes it less comprehendible to anyone not already familiar with the operator. Any actual Swift developer should be able to understand what's happening. But frankly, this isn't good code, and not just because you're using coalescing like that.
1. You should never have to use a raw object like that. Use a Decodable type and get a real Double from the parser. Among other things you have no error handling here to tell you when that as? Double cast fails. First thing you do in Swift is embrace the type system.
2. Fallbacks like that probably shouldn't be done inline. Instead, there's usually a facade on top of things like UserDefaults to properly name and handle different properties consistently. Using rawValue that much should be an obvious smell.
3. Use of untyped Any is almost always a bad idea in Swift. Create a proper type that encapsulates exactly what you should see and you'll likely write less code with fewer bugs.
4. A CLLocationDistance created from .greatestFiniteMagnitude is obviously an invalid value, so I assume you're checking it further down the line to see that. Better to just produce an error or a nil value when you don't have an actual distance than to pollute your system with invalid data.
Cool. If I'm doing it wrong, I wouldn't mind seeing it done right. I'm always willing to learn new stuff, and one thing that I've learned about Swift, is that there's always more/better ways to do stuff.
The obvious issue with not using rawValue, is that we don't use an enum, and that's what I usually see. I like to use enums, where others use static lets, because I can do things with enums, like limit the number of values (good for switches), and repurpose them, from time to time.
Also, since an enum is a type, I can add things like functions to do cool stuff, like extract and interpret the state, or do some good debug stringing. I could also use a struct, but why, if the enum will do it?
And, of course, since it's a type, I can extend it for special applications. I do that, a lot.
One of my "desmeller" exercises, is to go through my code, looking for "magic number constants," and see if I can replace them with enums.
The reason for the Any, is because the code extends another SPM module that I wrote, that forms an infrastructure for preferences, and this is just the bit inside the implementation.
No, the highest Double isn't an invalid value (that's actually the point). It's just one that won't apply to the filtered set that I produce, later on. That means I don't have to put in special branches (keeps the CC low), to look for invalid values.
I could also clamp it, but that can have unfortunate side effects, and I can add some assertions in the else clause.
Sometimes, there may be reasons for people doing stuff, other than they suck. I don't suck. I'm not being snooty, but I do this a lot, and have a lot of pretty good stuff, out there.
Maybe, and I know this is just crazy talk, I might actually be a halfway decent programmer.
1. You should never have to use a raw object like that. Use a Decodable type and get a real Double from the parser. Among other things you have no error handling here to tell you when that as? Double cast fails. First thing you do in Swift is embrace the type system.
2. Fallbacks like that probably shouldn't be done inline. Instead, there's usually a facade on top of things like UserDefaults to properly name and handle different properties consistently. Using rawValue that much should be an obvious smell.
3. Use of untyped Any is almost always a bad idea in Swift. Create a proper type that encapsulates exactly what you should see and you'll likely write less code with fewer bugs.
4. A CLLocationDistance created from .greatestFiniteMagnitude is obviously an invalid value, so I assume you're checking it further down the line to see that. Better to just produce an error or a nil value when you don't have an actual distance than to pollute your system with invalid data.