Only of the design goals of Swift is precisely not to be as low level as Rust, unless required to for high performance code, and had a few big names from C++ community involved in its initial versions.
True. I wouldn’t want to think about the borrow checker writing UI code, and I don’t need the performance or ultra-optimized machine code of Rust when I write Swift.
I moreso meant in terms of the high-level features of Rust and how they integrate FP-style patterns into a C-style imperative language. Like tuple-based structs as discussed above, or control flow as expressions, like if and match.
The alternatives to the latter in Swift are
A) defining a dedicated function for the control flow, using return statements
B) defining but not initializing a let constant before the control flow statement
C) using the ternary operator, which is concise but doesn’t really allow for destructuring complex types
all of which are more verbose, less clear in intent, and IMO don’t embody’s Swift’s mantra of “clarity at the site of use” as well as Rust’s approach.
Practically, there’s little difference. But as they say, naming things is one of the two hard problems in computer science and I’d rather avoid it wherever possible when the name inevitably doesn’t add any meaning, and arguably obscures it.
I could just use rawValue as the field name every time, but foo.rawValue is a lot less readable, IMO, than foo.0
I often find myself thinking of Swift as a not-quite-fully-baked attempt at making a Rust, and this reinforces my impression.