It's not the same as the Rust example because you're shadowing an ivar to a local, but since `self.` is implicit you're still shadowing.
You'll see the same in Rust
fn example(name: Option<String>) -> Option<usize> {
let name = name?;
Some(name.len())
}
fn example(name: Option<String>) {
if let Some(name) = name {
println!("{}", name.len());
}
}
> but since `self.` is implicit
To make sure I'm following, do you mean that Rust's `self.` is implicit in Swift?
struct S {
var string: String
func doSomething() {
// These two lines are equivalent.
print(string)
print(self.string)
}
}> do you mean that Rust's `self.` is implicit in Swift?
Swift's `self.` is implicit in Swift – in most contexts, to access a property the `self.` is not required. `self.name = "John"` and `name = "John"` are equivalent (assuming self is an object with a name property).
There are places where explicit `self.` is required though – when you want to differentiate between a shadowed local and a property (obviously), or when you're inside a closure (to make it clear that the closure is capturing self, not just capturing a reference to the property).
This is kind of a philosophical corner: can you shadow something that isn't there anymore? Once you've moved out of something, if you attempt to use the old name, then you'll get a compiler error different from "no such variable", so it's still there in some sense.
Pragmatically, I think you are on the money.