3 ms·

> for Optional promotion You'll see the same in Rust fn example(name: Option<String>) -> Option<usize> { let name = name?; Some(name.len(

> for Optional promotion You'll see the same in Rust fn example(name: Option<String>) -> Option<usize> { let name = name?; Some(name.len()) } Or fn example(name: Option<String>) { if let Some(name) = name { println!("{}", name.len()); } } A main difference is the requirement to use `Some`, which allows for the flexibility to apply to any enum. > but since `self.` is implicit To make sure I'm following, do you mean that Rust's `self.` is implicit in Swift?

mlex 8y ago
Yeah `self.` is implicit. In Swift: struct S { var string: String func doSomething() { // These two lines are equivalent. print(string) print(self.string) } }
favorited 8y ago
That all makes sense. I've only done a couple days of Rust, so my recollection is spotty. The shadowing makes sense because if a local variable was moved out, then you're not really shadowing it anymore. Is my understanding of that correct? > 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).
- shepmaster 8y ago
  > The shadowing makes sense because if a local variable was moved out, then you're not really shadowing it anymore. Is my understanding of that correct? 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.

mlex 8y ago

Yeah `self.` is implicit. In Swift: struct S { var string: String func doSomething() { // These two lines are equivalent. print(string) print(self.string) } }

favorited 8y ago

That all makes sense. I've only done a couple days of Rust, so my recollection is spotty. The shadowing makes sense because if a local variable was moved out, then you're not really shadowing it anymore. Is my understanding of that correct? > 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).

shepmaster 8y ago
> The shadowing makes sense because if a local variable was moved out, then you're not really shadowing it anymore. Is my understanding of that correct? 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.