Poll: what do you strongly dislike about Swift?

[phoneyDev (Stern)]

Slow compiling.
Weak debugger.
Obj-c exceptions kill my app.
Slowness of adoption of simple, obvious, methods to std library (clamped(to:), sum(), sorting by keypath, and plenty more pitches that have died on the vine).
I often hate optionals.

[young (rtSwift)]

@toph42

let optional1: Int?

this is initialized to nil

@toph42

let optional2: Optional<Int>

This is not

[Nobody1707]

Actually, neither of those are initialized to nil. Only optional vars are implicitly initialized.

[filip-sakel]

@young

.foregroundStyle(flag ? AnyShapeStyle(.tint) : AnyShapeStyle(.orange))

Self-conforming existentials would have allowed SwiftUI to accept any ShapeStyle, since AnyShapeStyle is probably what's stored under the hood anyway. Maybe that is still possible with overloading, if/when such a feature becomes available.

[ExFalsoQuodlibet (Elviro Rocca)]

I don't think I "hate" any Swift feature, and if I did in the past, it was usually because I didn't understand the reason behind that feature.

I think, though, that there are some clearly missing features, that I consider pretty natural and obvious, and whose lack requires several workarounds, but again, there are a lot of features that I personally don't use about which I’d be naturally inclined to think "why did they work on this useless features instead of my more important request?", but I see many other people using and enjoying these features so I eventually realized that I simply don't have the full context to complain about this stuff in good conscience. As an example from the other side:

@tera

ability to create custom operator symbols (even ascii!).

I'm instead glad that we have this in Swift, and I've been using for a long time a small bunch of custom operators that I find incredibly useful and that improved a lot my and my team's code, and I consider operator overloading (for things that are semantically unrelated) as a bad and confusing practice (even collection concatenation, in my opinion, should not use +).

But anyway, my top 2 missing features are:

• generic extensions (it can be done with a workaround, but only for functions), for example:

extension <T> Result where Success == Optional<T> {
  static var success: Self {
    .success(nil)
  }
}

• the ability to define custom pattern-match mechanisms, in order to bind values on types that are not enums, for example:

let array: [Int] = ...
switch array {
  case (_, let x, ...):
    print("The second element of the array is", x)
  default:
    break
}

[Karl]

I'm not comfortable with the word "hate".

There are certainly parts of the language where reasonable minds may differ, and sometimes my own opinion differs from the decisions that have been made. We all have our own perspectives, and my priorities and preferences are obviously rooted in what I personally want out of the language. But I don't hate it when others win the argument by presenting a more compelling case for their priorities and preferences.

Similarly, there are gaps I wish would be filled. But of course, I only have my own needs to think about; I don't really have any idea what the overall Swift developer community would benefit the most from, only what I personally struggle with. I also don't work on the compiler, so I'm free of the pressure of having to ship feature X otherwise a bunch of my colleagues can't ship their work. It's a luxury to be able to point to something and say "I hate this", without needing to understand the context in which it was created or having to deliver an alternative by a deadline.

By all means, question the parts of the language you think could be better, and advocate for alternatives, but I think the word "hate" is too strong. I don't think it's the right spirit - it's not what we do here. We don't "hate".

[taylorswift]

if you don't hate (insert critical infrastructure you rely on), you haven't used (insert critical infrastructure you rely on) enough

[toph42 (Topher Hickman)]

@idrougge

I quite like being able to use ° for degrees, for instance.

You’ve just helped me make a whole bunch of my SwiftUI drawing code look a lot cleaner and more succinct with angle = 30° in lieu of angle = Angle(degrees: 30). Thank you!

[idrougge (Iggy Drougge)]

I think there have been too many bespoke mechanisms added to the language since Swift 5.0 came out, which would have turned out better or even unnecessary had the technical underpinnings been grown better.

Result builders, @callAsFunction, @propertyWrapper, $propertyWrapper etc come to mind.

The features they represent could have been better if they weren’t so rushed, and they serve to make Swift a harder language to learn and teach than just a few years ago.

[dmk (Dmitry)]

Honestly, it seems for me that Swift has added too many specific features to handle them properly.
For instance, Self can be returned from a method:

func copy() -> Self

and can’t be a part of a returned tuple:

func updated() -> (Int, Self)

The type checker often can’t say the right reason why my code is invalid (especially in the latest versions). For simple expressions it works, yes, but for anything more complex…

Generic are a problem too. Swift is claimed to support OOP, however, I can’t create a variable/property to store anything conforming a protocol with an associated type. Which I think is one of the essentials of OOP, polymorphism.

It also makes me sad that Swift makes mocking (in testing, for instance) really difficult. Unlike Objective-C, there is no mocking library, no way to create anonymous objects, only code generation, which leads to increased project environment complexity, more problems for beginners, and more risks for CI/scripts.

[young (rtSwift)]

@dmk

I can’t create a variable/property to store anything conforming a protocol with an associated type

it is possible:

struct Foo<S1: ShapeStyle, S2: ShapeStyle> {
    let s1:S1
    let s2: S2
    init(s1: S1, s2: S2) {
        self.s1 = s1
        self.s2 = s1
     }
}

[ibex10]

I like this poll - Thank you!

What I hate about Swift: It is a magical language.

PS: I am sorry to say this: Swift is harmful to those starting to learn coding. They should start with C first and learn what happens when you malloc and forget to free.

[Lantua]

That's still too much magic and abstraction. You should start w/ assembly and Ralf Brown's interrupt list. What happens when you forgot to set EAX will surprise you!

[dmk (Dmitry)]

Yes, you’re right, I can choose what type I want to use for the concrete instance . But I meant storing any implementation that conforms to my protocol, something like the following

protocol ShapeStyle {
  associatedtype T
  // …
}

struct Foo {
  var s1: ShapeStyle<CGFloat>

  init(s1: ShapeStyle<CGFloat>) {
    self.s1 = s1
  }
}

var f = Foo(s1: A())
f.s1 = B()

[davdroman (David Roman)]

@RonAvitzur

How are they different?

@toph42

Huh?

Optional properties get unwanted default values in memberwise initializers

extracting from another thread. i believe this behaviour is broken and needs fixing: struct S { var a: Int var b: Int? var c: Int? = nil } let x = S(a: 0, b: nil, c: nil) // ok let z = S(a: 0, b: nil) // ok let y = S(a: 0, c: nil) // *** HHHMMM??? let w = S(a: 0) // *** HHHMMM??? this is because the synthesized memberwise initializer is generated as: init(a: Int, b: Int? = nil, c: Int? = nil) i believe this is a mistake and it should be generated as: init(a: Int, b: Int?, c: Int…

[Panajev (Goffredo Marocchi)]

Hate not being able to have argument labels on stored closures. Hate myself for not having the skills to help revert the damage caused by swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub that took them away :/.

[hassila (Joakim Hassila)]

@taylorswift

if you don't hate (insert critical infrastructure you rely on), you haven't used (insert critical infrastructure you rely on) enough

Well, just quickly proving this blanket statement wrong from my POV:

Electricity
Running water
Sewage
Internet access
Operating systems
Food distribution
...

I really rely on the above (and many more), used them intensely over several decades and have opinions on how they might be improved, but I hardly hate them...

I really agree with @Karl here - hate is a very strong word and there are a number of very significant considerations why things are like they are.

If anything, I feel that the uptake and success of Swift (that has many, many great features as outlined in the other thread - which is why most of us are here at this forum at the end of the day :-) ) might push the pace of the core team just slightly a bit too fast at times, but then, I'd rather have that and a great push forward of the platform than stagnation and no progress. It's a challenging balance for any product development team, presumably much more so for core tech like this.

[alan_szumy (Alan)]

@hassila

Well, just quickly proving this blanket statement wrong from my POV:

Electricity
Running water
Sewage
Internet access
Operating systems
Food distribution

+1. I for one am proud to live in a country where we can take reliable electricity and clean drinking water for granted. Cynicism has become so normalized these days.

[jaredh159 (Jared Henderson)]

• XCode - lack of customizability, plugins, vim support is extremely incomplete, and much more... I literally architect my code so I can spend as little time in XCode as possible, and do as much in Vscode.
• Testing from the command line - I don't like GUIs and clicking buttons for running my tests, I want to run them only from the command line, and Swift's (XCTests?) output is a giant wall of garbage that needs to be parsed and formatted, for which tools exist but are not good. The (gasp!) javascript community has far better tooling for CLI testing than Swift.
• It being trapped in the Apple ecosystem - Swift is such a fundamentally fantastic language, it's sad that it's pigeon-holed as a language for making iOS apps and takes a lot of pain to get working well outside of XCode. I know this is slowly changing, but I would love to see this speed up. Swift should be a in the discussion with Go and Rust for many applications, but sadly is usually not.

[young (rtSwift)]

@jaredh159

vim support is extremely incomplete

Big miss for me: the "." command: repeat the last edit action