| |
| ▲ | fauigerzigerk 6 hours ago | parent | next [-] | | I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers). I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined. I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess. I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable. I would probably remove async/await as well, but this is a broader debate beyond Swift. And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs. | | |
| ▲ | fingerlocks 4 hours ago | parent [-] | | I agree with you about result builders, silly feature that only exists for SwiftUI. But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice. |
| |
| ▲ | quietbritishjim 7 hours ago | parent | prev | next [-] | | I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language. * If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language. * Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them. * Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset. | |
| ▲ | cloogshicer 7 hours ago | parent | prev | next [-] | | But you have to know all of them to read other people's code. To answer your question: I would immediately get rid of guard. Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering. | | |
| ▲ | willtemperley 4 hours ago | parent [-] | | I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming. internal should definitely go though. | | |
| ▲ | cosmic_cheese 4 hours ago | parent [-] | | The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it. | | |
| ▲ | iamcalledrob 3 hours ago | parent [-] | | I think the ?: operator ends up being a decent alternative, e.g. // Swift
guard let foo = maybeFoo else {
print("missing foo")
return false
}
// Kotlin
val foo = maybeFoo ?: run {
print("missing foo")
return false
}
Unless there's a use case for guard I'm not thinking of |
|
|
| |
| ▲ | merlindru 5 hours ago | parent | prev | next [-] | | i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet | | |
| ▲ | willtemperley 4 hours ago | parent [-] | | It's true that internal is pointless. Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate. |
| |
| ▲ | eptcyka 7 hours ago | parent | prev | next [-] | | You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work. | | | |
| ▲ | troupo 7 hours ago | parent | prev [-] | | 1. You don't have to use it all, but someone will. And there are over 200 keywords in the language: https://x.com/jacobtechtavern/status/1841251621004538183 2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006 | | |
| ▲ | uasi 5 hours ago | parent | next [-] | | That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`). | |
| ▲ | dematz 6 hours ago | parent | prev [-] | | are there actually 217 keywords? Just wondering what the difference between that file and https://docs.swift.org/swift-book/documentation/the-swift-pr... (a mere 102 keywords) | | |
| ▲ | merlindru 5 hours ago | parent [-] | | That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/... I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle | | |
| ▲ | dematz 5 hours ago | parent [-] | | Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes... |
|
|
|
|
