Poll: what do you strongly dislike about Swift?

Avi · 2022-05-28T20:04:37.153Z

jarod:

Only getting the type name when printing an ObjC-based enum. We should at least get the raw value. I often end up needing to write some throwaway code to switch on every case and return / print a string when debugging, which is really tedious.

Use p instead of po. Yes, it's silly the "workaround" is needed, but at least you don't need code for it. What really needs to change in the debugger is making it work reliably for pure Swift code!

young · 2022-05-28T20:23:50.890Z

jarod:

Synthesized initializer limitations

I just hand code the init and give up on the synth’d one. I don’t like anymore special notation. Just hand code is the simplest most straightforward. For example, you cannot use synth’d init to initialize let Assigned with default. There was a pitch to add @initializable let x = xzy. But that’s just more stuff. Again simply write out the init and be done with.

Codable

You can customize a property field Codable with property wrapper. Not sure if this is the kind of thing you mean.

viktorcode · 2022-05-29T06:30:00.150Z

I don't like Swift compiler speed (for debug). It can be at least one order of magnitude faster. It sounds implausible, but only if you stick to the current file-based compiler architecture. Watch early videos on development of Jai language by Jon Blow; he explains few of the decisions he made to make his compiler faster. Having code compiled that fast opens new possibilities of using the language.

The rest of what I don't like is just some missing features which eventually will be there.

Hacksaw · 2022-05-31T06:30:54.872Z

I’m not a fan of the “put your special init into an extension to keep the synthesized init” behavior. It’s a magic semantic. In my mind, one ought never need to have an extension in the same file as the base declaration.

Jakub_Suder · 2022-06-03T16:04:00.777Z

For me:

that public and open are not the same thing like in most languages
lack of abstract classes / abstract methods
the unintuitive Yoda-speak way of checking enum cases with associated values (if case .x = value)
Codable not being able to decode from a JSON dictionary (only from Data)
anything that involves methods like index(before:) or index(after:) instead of just indexing by Int
that the typealias keyword is overloaded for protocols with associated types to mean something very different than elsewhere (specifying a type used in protocol conformance vs. just declaring an internal helper type)
anything that requires using terms like "type erasure" or "existentials" to explain
more dynamic things like stubbing/mocking in unit tests being basically impossible without rearchitecting your whole code with things like dependency injection (unlike in, say, Ruby)
and a bit of a nitpick, but I never liked the word "in" used for listing arguments to a closure, it somehow doesn't read well to me…

young · 2022-06-03T16:10:53.168Z

Jakub_Suder:

anything that involves methods like index(before:) or index(after:) instead of just indexing by Int

the index api is designed for opaque index type like String.Index, these are not Int. For Index type that's Int like Array, you can use Int to do index calculation.

Jakub_Suder:

anything that requires using terms like "type erasure" or "existentials" to explain

Agree! My post case in point.

smkuehnhold · 2022-06-03T16:34:19.681Z

that the typealias keyword is overloaded for protocols with associated types to mean something very different than elsewhere (specifying a type used in protocol conformance vs. just declaring an internal helper type)

I'm not sure what you mean here? You can do the same thing in structs/classes.

protocol X {
  associatedtype T
}

protocol Y: X {
  // Satisfying X
  typealias T = Int

  associatedtype U

  // defining a helper
  typealias Helper = String
  var helper: Helper { get }
}

class Z: Y {
   typealias U = Int

  // I believe you can even use Helper here 
   let helper: Helper
}

Jakub_Suder · 2022-06-03T16:43:07.129Z

smkuehnhold:

I'm not sure what you mean here? You can do the same thing in structs/classes.

I mean that as I understand it, the typealias T and typealias Helper in your example are two somewhat different features:

the second one defines a new type for the purposes of this class and its users, you can use any name you want for it since this is your own type and it can refer to anything you need
the first one kind of fills a placeholder defined elsewhere and it has to use this specific name without typos and it needs to fulfill some type conditions, otherwise if you misspell it it becomes the other case

This seems confusing to me, and I'd have used a separate keyword for the "fill in a placeholder" use case...

cukr · 2022-06-03T18:12:55.382Z

Jakub_Suder:

Codable not being able to decode from a JSON dictionary (only from Data )

It's possible, you just have to use a Decoder implementation that supports it, for example GitHub - elegantchaos/DictionaryCoding: Swift Decoder/Encoder which converts to/from dictionaries.

tera · 2022-06-03T19:21:31.623Z

Jakub_Suder:

Codable not being able to decode from a JSON dictionary (only from Data )

I remember using the trick: serialise Dictionary to Data using JSONSerialization and then deserialise Data into a value with JSONDecoder. Ditto for the other way around: JSONEncoder → JSONSerialization → Dictionary.

tera · 2022-06-03T19:40:52.942Z

young:

What kind of code prefix/postfix -- / ++ operators make them better than without? Can you show examples? I feel with -- / ++ code is more terse but may not necessary clearer. Perhaps I just don't get it.

// without ++
func readByte() -> Byte {
    let result = bytes[readPos]
    readPos += 1
    return result
}

// with ++
func readByte() -> Byte {
    bytes[readPos++]
}

// same but exposed as an "postInc" function:
func readByte() -> Byte {
    bytes[postInc(&readPos)]
}

// compared to "+=" "preInc" / "postInc" functions have return value:

bufferPos = preInc(&readPos, bufferSize)

// besides as mentioned before it can be made atomic while this is inherently non atomic:

readPos += bufferSize
bufferPos = readPos

tera · 2022-06-03T23:42:48.205Z

jarod:

Synthesized initializer limitations. You can't use them for classes or in a public API, and they go away as soon as you need an additional initializer or a little bit of extra logic. I'd really like an explicit syntax for memberwise inits that lets you have control over access level and extend them, i.e. public synthesized init() { extra logic } . Or maybe a special memberwise parameter placeholder so you could do things like this: public init(#members, extraParams: String...)

Yep, or something simple like this (can work for structs as well):

class A {
    var x: Int
    var y: Double = 2
    var z: String
    
    init(x, y, z) // standard "memberwise" init
    /*
     init(x: Int, y: Double = 2, z: String) {
        self.x = x
        self.y = y
        self.z = z
     }
     */
    
    init(_ x, with y, and z) // with external parameters
    /*
     init(_ x: Int, with y: Double = 2, and z: String) {
        self.x = x
        self.y = y
        self.z = z
     }
     */
    
    init(y, x, z) // with different parameter order
    /*
     init(y: Double = 2, x: Int, z: String) {
        self.y = y
        self.x = x
        self.z = z
     }
     */
    
    init(x, z) // can omit defaulted params
    /*
     init(x: Int, z: String) {
        self.x = x
        self.z = z
     }
     */
    
    init(x = 1, y = 3, z) // with default value
    /*
     init(x: Int = 1, y: Double = 3, z: String) {
        self.x = x
        self.y = y
        self.z = z
     }
     */
}

ExFalsoQuodlibet · 2022-06-04T09:12:35.427Z

You can do it like this:

func readByte() -> Byte {
  defer { readPos += 1 }
  return bytes[readPos]
}

jayton · 2022-06-04T10:41:10.485Z

Jakub_Suder:

the first one kind of fills a placeholder defined elsewhere and it has to use this specific name without typos and it needs to fulfill some type conditions, otherwise if you misspell it it becomes the other case

This is exactly the same as fulfilling a protocol method or property requirement, though.

Jakub_Suder · 2022-06-04T15:17:15.303Z

jayton:

This is exactly the same as fulfilling a protocol method or property requirement, though.

To be honest, I've just watched a talk yesterday where there was an example of fulfilling an associated type requirement by declaring a new enum type instead of typealiasing an existing type, which I didn't know was possible... So yeah, I guess from this perspective it does make sense, I wasn't thinking about it this way.

Jakub_Suder · 2022-06-04T15:18:43.447Z

tera:

I remember using the trick: serialise Dictionary to Data using JSONSerialization and then deserialise Data into a value with JSONDecoder . Ditto for the other way around: JSONEncoder → JSONSerialization → Dictionary .

Yeah, but this really should be simpler and built-in… But thanks for the link @cukr

young · 2022-06-04T15:41:12.488Z

Can you give the link to the talk?

Thanks!

Jakub_Suder · 2022-06-04T15:47:22.486Z

young:

Can you give the link to the talk?

"What's new in Foundation" from 2021, @ 10:30

dhoepfl · 2022-06-27T06:08:31.053Z

Type system

Swift(c) is non-deterministic: Valid code might not compile because the compiler fails to resolve the types within a given time. (let x = 1 + 2 + 3 + 4 + 5 + 7.0 + 8 fails to compile on some of my machines.)
(Lack of) implicit type conversion rules: let d = 7.0; let x = 1 + d works but let i = 1; let d = 7.0; let x = i + d does not. (type(of: 1) == type(of: i) is true)
Strings not having Integer subscripts. I understand the reasons but in 99.9% of all use cases, I simply do not care. It does not matter, even. Remember: I’m saying that while using a machine that is too slow to compile a simple addition.
Substring should be a subclass of String, ArraySlice a subclass of Array, etc. It’s okay to write Array(x[4..7]) if I want/have to release memory but most of the time I do not care. This should be true: Array(x[1...2])[1] == x[1...2][1]

Direction of Swift

Domain Specific Languages. It’s my fear that in a few years, you will have to know several different languages to understand Swift code.
New features seem to get released before they are (what I consider) production ready:
- Concurrency that was not available for Linux/older macOS/iOS.
- Some Foundation types are not sendable. (Who would want to pass an URL to a task?)
- Releasing “unfinished” sets a bad example, related frameworks tend to do the same. Looking at your, SwiftUI (even the demo code crashed for one or two years).
The same is true for proposal reviews: There have been several second, third, and even forth reviews of a proposal. As I understand it, the proposal review should be at the end of the process, not in the middle. Sure, second reviews can occur but the normal should be that questions have been resolved beforehand.

Bug handling

Server side support is poor.
Bugs in macOS hold back fixes in Foundation. A bug in macOS/iOS should never prevent a fix in the open source implementation of Foundation.
Fixing bugs should be top priority: Currently there are 4333 open issues that are labeled as bug, with only 6179 closed. This means more than 40% of all bugs ever reported for Swift are unresolved.

Forum/Community

American discussion culture is expected in the Forum: I have seen moderators saying that someone’s tone was “not appropriate”. I (as a German) did not see any problem. In fear of being considered rude, I’ve discarded more comments than I posted (this post lives as a draft for quite a while now - weeks) and it takes a lot of time to rephrase what I post to make somewhat sure my comments are not considered rude.
The imbalance in power between community and core team: For example, in the first review of regex literals, counted after improvements, 29 people clearly said they are against /…/ and 13 said they are in favor of /…/. Even though more than twice as many were against it than in favor of it, it never felt like the core team truly considered giving up on /…/.
This also shows in Xcode 14b1, which seems to set a de-facto decision before the formal review has ended.
This is related to the previous point: An open “We do not think that the examples of breaking source matter in practice. We tested it on x million lines of code and found only 1 line that had to be changed. In the light of the deadline for Xcode 14b1, we already decided to go with /…/, so there is no point in further discussion.” would have helped a lot.
End dates in reviews are often ignored. If the review period is extended, this should clearly be communicated. (Again, the regex review as an example: It ended on May 23rd. 48 of 118 posts were added after that date, the latest post is from Jun 11th - 18 days after the 7 day period. One month later, it is still open for comments.)
To me it feels like open sourcing Swift is (from the Apple side) considered a requirement, not something they want to do. It’s the open source project where I feel least welcome to contribute.

Closing

All of the above is my point of view. I understand there are good reasons for why it is as it is. I understand that some of the things I mentioned above only exist in my head. I understand that most (or all) of the above can not and therefor will not change. I will read answers but I will not defend my points.

scanon · 2022-06-28T15:37:02.110Z

dhoepfl:

For example, in the first review of regex literals, counted after improvements, 29 people clearly said they are against /…/ and 13 said they are in favor of /…/. Even though more than twice as many were against it than in favor of it, it never felt like the core team truly considered giving up on /…/.

This has come up a few times in the past, but it's worth mentioning again: evolution reviews are not votes. What mattered to the core team, and now matters to the language workgroup, are the merits of the arguments and alternatives that are put forward, not the number of people who argue them. Otherwise popular evolution reviews have frequently changed course entirely on the basis of a single comment pointing out a problem that hadn't been noticed before, and lots of people saying that they don't like something doesn't carry a lot of weight if the reasons they give have already been anticipated in the proposal and discussed.