The basic problem of Swift

[ubu]

@Jon_Shier

software quality has benefitted as a result.

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.

[xwu (Xiaodi Wu)]

@ubu

That's a claim without evidence and yet it's the core of your argument. Is it possible that code that you wrote in ObjC wasn't safe, and if so then then shouldn't you have written better ObjC code?

@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?

[ubu]

@xwu

What ideas regarding changes to the language are you bringing forward

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.

[Jumhyn (Frederick Kellison-Linn)]

@Jon_Shier

I suggest you research the initial reactions to Swift in the Obj-C community, null safety in general, and the syntax of other modern languages and how they deal with nullability.

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

Null References: The Billion Dollar Mistake

[Lantua]

@ubu

Saying that [...] other not very popular languages also use it isn't a good justification for it.

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.

PS

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

[xwu (Xiaodi Wu)]

@ubu

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.

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:

On the road to Swift 6

The Swift project has achieved a critical milestone of maturity of the core fundamentals, providing stability for users to invest in using Swift in earnest. On Apple's platforms such as macOS and iOS, the arrival of ABI and module stability has enabled the creation of stable binary frameworks. Further, the Swift Package Manager, which has integrated support both in Xcode and other IDEs, provides a cross-platform solution for building and distributing Swift libraries. Put together, these form …

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

[ubu]

@Jumhyn

the person widely credited with inventing the null reference

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.

[xwu (Xiaodi Wu)]

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!

[GreatApe (Gustaf Kugelberg)]

@ubu

The optionals problem and arcane syntax just don't exist in most other languages. For instance in ObjC its equivalent is the practice of comparing pointers to nil, which everyone does as a matter of course and doesn't require a new language feature.

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.

[ubu]

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

[ubu]

@GreatApe

optionals alone are enough to motivate the creation of Swift

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

[GreatApe (Gustaf Kugelberg)]

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.

[xwu (Xiaodi Wu)]

@ubu

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

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.

[GreatApe (Gustaf Kugelberg)]

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
}

[ubu]

@GreatApe

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.

[ubu]

@Lantua

So yea, it seems like a coming trend.

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.

[GreatApe (Gustaf Kugelberg)]

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

[ubu]

@GreatApe

it is powerful

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.

[GreatApe (Gustaf Kugelberg)]

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

[ubu]

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.