| ▲ | kridsdale1 13 hours ago |
| I really like modern Swift. It makes a lot of what this author is complaining about, impossible. The worst file I ever inherited to work on was the ObjC class for
Instagram’s User Profile page. It looked like it’d been written by a JavaScript fan. There were no types in the whole file, everything was an ‘id’ (aka void*) and there were ‘isKindOfClass’ and null checks all over the place. I wanted to quit when I saw it. (I soon did). |
|
| ▲ | JackYoustra 11 hours ago | parent | next [-] |
| Modern swift makes this technically possible but so cluttered that it's effectively impossible, especially compared with typescript. Swift distinguishes between inclusive and exclusive / exhaustive unions with enum vs protocols and provides no easy or simple way to bridge between the two. If you want to define something that typescript provides as easy as the vertical bar, you have to write an enum definition, a protocol bridge with a type identifier, a necessarily unchecked cast back (even if you can logically prove that the type enum has a 1:1 mapping), and loads of unnecessary forwarding code. You can try and elide some of it with (iirc, its been a couple years) @dynamicMemberLookup, but the compiler often chokes on this, it kills autocomplete, and it explodes compile times because Swift's type checker degrades to exponential far more frequently than other languages, especially when used in practice, such as in SwiftUI. |
| |
| ▲ | tizio13 11 hours ago | parent [-] | | I think you’re conflating 'conciseness' with 'correctness.' The 'clutter' you're describing in Swift like, having to explicitly define an Enum instead of using a vertical bar |, is exactly what makes it more robust than TS for large-scale systems. In TypeScript a union like string | number is structural and convenient, but it lacks semantic meaning. In Swift, by defining an Enum, you give those states a name and a purpose. This forces you to handle cases exhaustively and intentionally. When you're dealing with a massive codebase 'easy' type bridging is often how you end up back in 'id' or 'any' hell. Swift’s compiler yelling at you is usually it trying to tell you that your logic is too ambiguous to be safely compiled which, in a safety first language, is the compiler doing its job. | | |
| ▲ | JackYoustra 8 hours ago | parent | next [-] | | I mean there should be _some_ sugar in a language like swift, no? It has sugar in many parts of the language, being able to define a simple type union should not require custom declaration of every forwarding accessor, a protocol, an enum, bridging back and forth between them, etc. It would be one thing to say that the vertical bar is a shortcut for these more exhaustive constructs (setting aside whether these constructs are actually exhaustive - they're not really for the purposes they're used for in practice), but as it is right now, you have no bar! If it were simple and easy to use you'd have enums dictate the state of every app which, as any app developer knows, is not how its currently done! Swift enums are so hard to use you have just a mess of optionals on view state instead of how it should formally be done, where almost every non-trivial view has a single state that's an enum of all possible configurations of valid states. Indeed, if you put in a ton of effort to try and go down this route defining views "properly" with something like Swift TCA, you're not going to be able to get there even if you break up your app into 40 different targets because incremental recompilation will take a few minutes for something as simple as a color change. | |
| ▲ | llmslave2 9 hours ago | parent | prev [-] | | This is just cope. Swift's compiler doesn't choke because your logic is too ambiguous, it chokes because it's simply too slow at inferring types in certain cases, including a very common case where you write a normal Swift UI view. There is nothing ambiguous about that. Secondly, I'm not sure why you think the mountains of boilerplate to replace | leads to semantic meaning. The type identifier itself is sufficient. | | |
| ▲ | lmm 2 hours ago | parent [-] | | | is a massive footgun because it's usually exclusive in practice and occasionally silently inclusive. Having it in a language is a mistake, even if it superficially seems to make things easier, just like e.g. null. |
|
|
|
|
| ▲ | glenjamin 11 hours ago | parent | prev [-] |
| Any advice on how to learn modern Swift? When I tried to do learn some to put together a little app, every search result for my questions was for a quick blog seemingly aimed at iOS devs who didn’t want to learn and just wanted to copy-paste the answer - usually in the form of an extension method |