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.
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:
have(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.
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.
I highly suggest you watch the linked talk, particularly the portion beginning around the 30-minute mark, Programming languages should be responsible for their users. This idea that programmers should simply not write bugs is well-worn at this point, and (thankfully) on the decline.
Complexity and readability are not mutually exclusive. The constructs Swift uses mostly reflect pre-existing design patterns, but restrict the ability to misapply them.
Think of Swift like a saw with a riving knife. You have the ability to remove the safety measures, but you almost never should, and if you do it is your fault when you get hurt. The rest of the time, you don’t have to worry as much.
Sure, I'll check it out. But the premise that languages should be responsible to their users also includes being easy to get back into after using other languages. If arcane syntax and concepts (secret handshakes) are the modus operandi for a language, that's the opposite of being responsible.
To me it's more like the opposite of a "bicycle for the mind". It's the Freemasons coming up with arcane symbols and rules to exclude, not to facilitate work.
You keep saying “arcane”, but I can’t really say any of Swift’s language features fit that bill.
Swift is quite readable even to people without a programming background, in my experience. It’s generally self-explanatory, with the exception of special naming conventions like subscript and callAsFunction. You just have to know about those, I admit.