Poll: what do you strongly dislike about Swift?

idrougge · 2022-05-14T19:50:05.989Z

tera:

I believe removing these features would make Swift simpler and overall better, not worse.

I think one thing which makes Swift great, and a much greater language than many other languages of its generation, is that its creators didn't assume that they knew exactly how the language would be used or what its feature set should be.

I basically never write custom operators, but one of my first Swift programs was a hashing algorithm. Hashing often involves bit-twiddling, and Swift offers both binary NOT/AND/OR operators (~, &, |) and bit shift operators (<< and >>). What it doesn’t offer is a rotation operator, even though rotation is a common operation in CPUs. Thanks to Swift’s open-endedness, I could, as a novice, create a rotation operator >>> and write a more succinct algorithm than otherwise.

And I wouldn’t have been able to do that in other languages.

taylorswift · 2022-05-14T19:53:03.847Z

i like the custom operators in principle. non-ASCII unicode operators were a terrible idea.

cukr · 2022-05-14T20:07:55.001Z

Tools.
Swift debugger fails to print the value of a variable a lot of the time, and even when it succeeds it might print a different value than the one in a real program

Installing swift on linux is an awful experience The current state of Swift for Server and Linux - #18 by cukr

sourcekit-lsp is incomplete, lacking stuff like formatting and global rename

I dislike Xcode in general, for example spm integration is done poorly.

RonAvitzur · 2022-05-14T20:11:12.794Z

tera:

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

How are they different?

hooman · 2022-05-14T20:14:09.125Z

For me, it is the bolt-on feature creep of recent years. There are too many features added for the pragmatic reason of urgently addressing some specific needs of Apple framework API developers without putting enough time and effort into keeping the logical foundation of the language simple, sound, consistent and orthogonal.

We should have used this time and effort to design some foundational enabling features that would make most of these (now bolt-on) features into library-defined extensions of the language written in Swift itself instead of being baked into the compiler and written in C++.

There are also some regrets about some of the original design choices. (If you haven't seen it already, check out @jrose 's insightful Swift Regrets series.)

My biggest regret is the choice of Int as the Collection.Index type of Array. The semantics of Collection should require Index to be opaque and it should not be possible to construct or manipulate it without using the Collection API.

What we needed instead (that now we can't have), was an Int subscript on RandomAccessCollection as the offset into the collection elements. This would let us address Array (and its slice) elements with always zero-based Int offsets (as opposed to indices). This would make a consistent and well-defined Int offset available on all random-access collections.

We could also define special meaning for negative offsets to indicate reverse offset (offset from beyond end or endIndex) which would make a[-1] the always valid way to refer to the last element of any non-empty array. That would make addressing and slicing relative to the end of an array very easy.

taylorswift · 2022-05-14T20:14:09.257Z

i believe she/he is referring to What is a 'variable initialization expression'?

idrougge · 2022-05-14T20:14:38.956Z

taylorswift:

non-ASCII unicode operators were a terrible idea

Not as terrible as ASCII-only operators. I quite like being able to use ° for degrees, for instance.

hooman · 2022-05-14T20:17:05.715Z

Actually, they are one of my favorites and I (ab)use them often.

It depends on the domain. They are very useful for domain-specific libraries that manipulate domain-specific currency types.

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.