The basic problem of Swift

That's not actually true based on the Swift code I've seen in industry. There is a lot of force unwrapping out there that causes app crashes, because of the confusion that people have about optionality.
Swift's designers have tried to get too clever with the syntax and that has established what I call a set of secret handshakes that don't benefit anyone and don't improve software quality.

@ubu, this is a working forum for evolution of the Swift language. What ideas regarding changes to the language are you bringing forward, and what sorts of feedback on those ideas are you hoping to solicit from the community to help you to drive them to a proposal stage?


Eliminate any syntax that is "too clever by half". If you spend 6 months away from Swift and come back to it, much of its syntax is arcane and only shared with some unpopular languages. Eliminate anything that is arcane and unintuitive. People are writing bad Swift code because they don't understand the syntax and concepts. Make optionals optional i.e. they shouldn't be required. I think a lot of the promise of Swift has been wasted by people making it so arcane.

Just to point to one (oft-cited) reference in this space, from the person widely credited with inventing the null reference:


I'm not sure if trolling, but the wiki, has 20 languages (well, 18-ish), including the Kotlin. Most of which seems to be introduced in the past few years. So yea, it seems like a coming trend.


This might fit better w/ a more general #swift-users thread.

You’re are certainly entitled to your opinions, but significant changes to the syntax are not within the scope of Swift’s evolution at this stage.

You can learn more about the roadmap to Swift 6 here:

For more on Swift’s evolution process, see this document.

1 Like

Everyone regrets writing bad code. Dereferencing a NULL pointer is a boo-boo, but if it causes a $1 billion loss, it is ridiculous to blame the language and not the programmer. This is like saying that saws are sharp and he cut himself, then he blames the saw. That's childish. He should blame himself.

There are various forums to debate one’s opinions about various programming languages, but the Swift Evolution Discussion category isn’t the place.

Please see the documents I linked to about about the process and priorities for evolving to Swift 6. Thanks in advance for keeping this a place of professional and focused discussion!


I'm not sure what "the optionals problem" is, but I don't think I'm alone in thinking that optionals alone are enough to motivate the creation of Swift. Having the compiler keep track of which variable can and can not be nil saves a ridiculous amount of energy. If that was the only feature in Swift it would be worth it.


OK sure. So then I will make one concrete suggestion. Use this syntax instead of a?.b:
The word have expresses a clear and appropriate meaning, whereas ? is ambiguous and means different things in different contexts.

That could have been added to ObjC without the need for a new language.

Yes, and that would have been an amazing improvement.

Now we got much much more than that, powerful value types, strict types, super powerful enums, generics, some basic functional programming support in the std lib, and of course less needless verbosity. Swift is not perfect but it's much easier to use than ObjC in every possible way.

1 Like

Again, changes in basic syntax are not on the table for Swift 6. Please review the documents I’ve linked to above about our priorities and the process for Swift Evolution.

This is the main meaning of ?, and it's extremely convenient and intuitive. If you want to make it less ambiguous, remove the ? in pattern matching, that one is a bit surprising. Very powerful once you get it though.

enum Bla {
    case someCase(String?)

switch x {
case .someCase(let xyz?) // Will only match when `xyz` is non-nil

This is just the sort of arcane stuff that not helpful. The meaning of it is not immediately clear. It is precisely the kind of "secret handshake" that I am saying should be eliminated.

OK but just a reminder, newness does not imply goodness. It's the logical fallacy Argumentum ad Novitatem: Appeal to novelty - Wikipedia
Example of things that were once new but proved quite horrible: Smoking, fascism, and cocaine.

It's very helpful in that it is powerful, but it's not harmful since you don't have to use it.

It may be, but most people coming back to Swift will look at it and think "what on earth does that do?".
If we were talking about a secret button in James Bond's car that does some amazing thing, OK it would be fun.
But we're talking about code and if what it does is misunderstood, a code reviewer might miss a critical bug.

I don't think you should be relying on code reviewers that only have a casual acquaintance with the language.

Fair point but as time goes on, I'm seeing Swift become more and more arcane. At some point, you'll have teams where no one fully understands all of its intricacies and code reviews will be imperfect. It will be like that car that no mechanic fully specializes in and is impossible to get repaired.