Poll: what do you strongly dislike about Swift?

taylorswift · 2022-05-14T20:17:52.373Z

how do people using your library type them? for that matter, how do they google them?

hooman · 2022-05-14T20:21:20.440Z

These are not typical libraries meant for general consumption. Professionals (engineers/scientists) know what those currency types represent and what those custom operators do. It helps them translate something close to their normal engineering/scientific notations for those concepts into Swift programs.

young · 2022-05-14T20:30:11.947Z

hooman:

bolt-on feature creep of recent year

An example of this is SE-0293 xtend Property Wrappers to Function and Closure Parameters: something wrong at the call site, the compile error show up at the function definition.

Or property wrapper composition: it only work in some cases.

t8n · 2022-05-14T20:52:40.656Z

enum case comparison (with associated values) - almost always the associated value needs to be ignored

tgoyne · 2022-05-14T22:40:01.824Z

The compilation speed.
Doing anything with generics regularly makes me wish I was writing C++. Swift's compiler errors with generics are usually entirely worthless beyond reporting that there's a type error of some sort. The lack of a spec and incomplete implementation means that I'm often not sure if I'm doing something invalid or if it's something conceptually valid that just isn't implemented yet (or sometimes it turned out I did something invalid which accidentally worked).
Everything related to Codable.
All the brittle compiler magic that makes 80% of scenarios nice and the other 20% awful because the compiler magic is there instead of an important feature.
Result builders.

young · 2022-05-14T23:03:34.170Z

Generic function parameters cannot have default values:

This doesn't compile:

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

so you wonder why doesn't it work?

Jon_Shier · 2022-05-14T23:19:00.723Z

Pretty this is fixed in Swift 5.7.

toph42 · 2022-05-14T23:43:13.905Z

tera:

T? not being exactly the same as Optional<T> .

Huh?

let optional1: Int? = nil
let optional2: Optional<Int> = nil

let same = type(of: optional1) == type(of: optional2) //true

phoneyDev · 2022-05-14T23:49:15.685Z

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 · 2022-05-15T00:04:06.455Z

toph42:

let optional1: Int?

this is initialized to nil

toph42:

let optional2: Optional<Int>

This is not

Nobody1707 · 2022-05-15T00:45:00.856Z

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

filip-sakel · 2022-05-15T10:04:24.842Z

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 · 2022-05-15T11:08:06.582Z

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 · 2022-05-15T13:12:23.687Z

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 · 2022-05-15T15:09:09.801Z

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

toph42 · 2022-05-15T15:40:58.539Z

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 · 2022-05-15T15:43:35.031Z

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 · 2022-05-15T20:46:40.683Z

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 · 2022-05-15T21:14:19.076Z

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 · 2022-05-16T03:43:42.629Z

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.