And the lack of namespaces. I so would like C#-style namespaces.
7 Likes
"Hate" wasn't actually that powerful a word in this context because it wasn't literal. But now the word "strongly" is here, so it's more accurate, but also more negative. 
8 Likes
- Using Swift in Xcode is just unpleasant. The compiler is slow, the debugger breaks far more often than it works, and the app overall just has too much focus on annual new Features they can trot out on a WWDC keynote slide, and not enough emphasis on the fundamental developer experience. sourcekit-lsp does not yet seem to be reliable enough for a user of VSCode or vim or whatever to be able to have their project Just Work without fussing.
- Building any large project effectively requires a lot of excessive modularization (which means a lot of developer time on overhead spent on modules).
- Unit testing not allowing access to private members. "But you're supposed to test the API, not the internals" is an idea that doesn't work when you need to be able to write a test for a bug fix, or for feature flagging, or whatever. I have to bend my code into pretzels adding nonsense to an interface to test things in Swift, and it is a significant waste of time that would be avoidable if I could just test a private variable.
- Also in JavaScript land, you can set up your unit tests to run in real-time when you change files. That would be nice to have. Especially if tests could live alongside files, rather than in a separate module because that's how Objective-C decided to do it 20 years ago.
7 Likes
Agree here, though to be fair the server-side Swift experience seems smoother overall, at least debugging is faster and more reliable. Swift's awkwardness on iOS (and macOS?) is likely coming from the fact that it should deal with a few gigantic ObjC frameworks.
Iām sure I could think of a list of annoyances about Swift as a language but I canāt think of a single annoyance about the language that harms my productivity more than what Steve mentioned a few posts upā¦the compiler speed and Xcode performance.
Yes, I know Xcode isnāt Swift and so I guess this is off topic, but honestly most people write Swift code in Xcode and the developer experience has got steadily worse over recent years. Whilst I can recognise some of the improved features in Xcode is is slow, buggy and unstable. The last few releases have been particularly terrible for crashes and the Xcode release cycle is too long.
Can we have a āsnow leopardā release for Xcode please?
4 Likes
i would agree that this is one of the largest things bottlenecking my productivity, but i am not sure what, if anything, could possibly be done about the compilation speed. personally i have made peace with the compile times. i suppose it is one of the necessary tradeoffs of using a language that tries to be expressive and performant at the same time.
Absolutely agree. Making enums, when you just need a namespace, makes me sad
9 Likes
It must be very difficult to implement the ā.ā command in Xcode. Thatās why itās not implemented.
Itās not vi without this. I really love vim mode because I know vi from so long ago my finger just do it without thinking. But when things do not work, itās WTF!
Just wish vim mode is more complete. I know it cannot be 100%, But the ā.ā command is a must! How can it be not.there?
I think universal equality & hashability is a big missed opportunity.
Lack of abstract classes once was a big challenge for me. I had a use case where clients must inherit implementation from the base class provided by the framework, and they must implement few abstract methods. I was lucky in my case to be able to decompose into concrete base class and protocol, but resulting generic signatures were complicated, required a lot of experiments to figure out, and were crashing compiler from time to time.
Tooling is causing some issues - I'm working on a huge mixed Swift-ObjC codebase and for some modules Swift debugger does not work and I have to resolve to print-debugging.
1 Like
I don't doubt that it's not trivial to implement something like the . command in vim. But, as a counterpoint, the vscode community-provided vim extension supports it perfectly, plus many other non-trivial vim features (like macros). That's why I really wish that Apple would work on providing a safe plugin API, so that the community could solve all of these problems themselves, and they could work on other things, instead of re-implementing vim inside Xcode.
2 Likes
Not being able to to declare static variables within a function. The only option is to litter the app with globals.
4 Likes
I think it's better to just have your variables owned by some kind of state object that's at the root of the view hierarchy that owns it, (like the environment object pattern in SwiftUI).
Static variables remove one downside of globals (unfettered access to read and write from anywhere), but they still have some of the other big downsides: they're thread unsafe unless you manually do something to synchronize them, and they make your functions impure
1 Like
Then I'll rephrase my "dislike"...
Not being able to declare a thread safe long-living local variable within a function.
I know we can do this, but I don't know if its thread safe.
func next() -> Int {
struct S { static var v = 0 }
S.v += 1
return S.v
}
If it is thread safe (and legal), could it be typealiased in some way?
Static variables are not thread safe. You'd need to protect it by mutex or make it atomic (which works with simple types like the presented), both of these can be hidden, so you'd get a nice:
func next() -> Int {
struct S { static var v = AtomicInt(0) }
return ++S.v
}
Thread safety aspects aside, kudos for inventing static variables in swift functions!
PS. static variables in C are not thread safe either.
1 Like
What you might be thinking of is the fact that global variable initialization is thread safe. I.e. they're all lazy loaded, but thread-safely, as if you had done dispatch_once on every access.
They're not synchronized as far as regular mutations go, however. That's where actors come in, which is how I would solve this problem in most cases.
Edit: this is a pretty interesting topic on its own. Shall we move it into a new thread?
1 Like
I've seen many people asking about this on various websites, so perhaps a new thread could be helpful. Please go ahead, but I doubt I'll be clever enough to contribute. I'm much better at asking questions.
But static variable in structs / classes also have these two downsides... (and we still have static variable in structs / classes.)
1 Like
I don't recall subclassing being complex, how do you mean?
Itād be nice if we could remove some complexity from final classes and allow things like memberwise inits.
If we are going to do this thread, might as well do it right. 
I really want structural sum types, i.e. types which bear the same relationship to enum that tuple bears to struct.
4 Likes