Hot take incoming…

All I want from Swift is a fast compiler that gives actually useful error messages. Enough syntax sugar. Oh and also, Swift Concurrency has been a disaster.

@ryanashcraft I especially enjoy it when I add a required initialization parameter to a SwiftUI view, but forget to update an existing call site somewhere, and the compiler just falls on its face trying to figure out what's wrong.
@jnouwen it's absolutely ridiculous
@ryanashcraft hot take: that’s not a hot take
@ryanashcraft not trying to be obnoxious. It just seems to me that the vast majority of devs who have been working on even a moderately complex SwiftUI have run into ridiculous error messages, concurrency errors that are inscrutable, and many minute build times. I honestly miss Objective-C’s simplicity and speed. Swift is great in some ways. All the areas you’ve outlined resonate with me and others I talk to.

@ryanashcraft The syntax sugar we got: `unchecked @Sendable`

The syntax sugar we wanted: `"0123456789abcdef"[x & 0x0f]` (aka int based subscript for strings)

#Swift

@teilweise
I am pretty sure because strings aren’t necessarily utf8 you could implement this but would came with a big performance hit.
Swift wants to encourage fast code. “Hello”[3] isn’t fast and can’t be fast in Swift

@hannesmnagel The performance hit is not a good reason. If I need the 4rd character of a string, I will access it:

`"Hello".dropFirst(3).first!` is by no means faster.
The same for `"Hello".unicodeScalars[3]`,
or `"Hello".prefix(4).suffix(1)`,
or `let temp = "Hello"; temp[temp.indices[3]]`,
or `let temp = "Hello"; temp[temp.index(temp.startIndex, offsetBy: 3)]`.

The reason that the subscript in `Collection` is documented to be O(1) is weak, too: subscript[Index] has to be O(1), but Index!=int.

@teilweise
"s[3]" would look cheap but isn’t, and Swift wants to make that cost visible.
But if really necessary it can be done.
I think that decision makes sense, but can understand your frustration.