4 ms·

> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the fir

> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in. Nope, that would be a static function on your struct. By using self you let the compiler know that you want to use an instance function.

nevi-me 4y ago
I prefer self. The changes in ES5 in JavaScript were painful because some people kept losing track of `this`'s scope. IIRC it changed with arrow functions, making it hard to know what `this` the code was using. I prefer an explicit `this` or `self` being passed, so that I know where it's defined. Something close enough, Kotlin uses `it` in lambdas. If you're nesting your lambdas, it can be tricky to review the code when just staring at it (when the IDE isn't helping you with types).
nneonneo 4y ago
Also, there are several different ways to pass self: `self`, `mut self`, `&self`, `&mut self`, and they have very different semantics. Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. but I feel like the explicit `self` is very clear and easy to understand.
- masklinn 4y ago
  > Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. `fn Box foo()`? `fn Arc foo()`? It also requires more parser lookahead. The `mut` case is also very odd, as it's not part of the function API (it just configures the binding of the internal local). Plus if self was implicit it likely would need to be a keyword, so that wouldn't be a usecase at all anymore.
  - pkolaczk 4y ago
    IMHO that would be a dead end. I prefer passing self explicitly and I still hope it will be possible to bind self partially in the future, e.g bind only one field. Currently if you call a function that e.g returns a reference to a field, the compiler borrows the whole self, not the field. So partial borrows are supported partially : they can't cross function boundaries.
    - masklinn 4y ago
      Yeah partial borrows are not part of the file system, which makes a lot of sense as it would severely leak implementation details. I regularly get frustrated but I don’t really see an easy alternative, it’s be a lot of work having it work let alone contextually (e.g. from pub functions for pub fields but not for private types / fields), and how would you even express the borrows / holes?
optymizer 4y ago
what if there's no static function with that name?
- masklinn 4y ago
  There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box<Self>) {} } impl Foo { // instance, refcounted fn foo(self: Rc<Self>) {} }
  - optymizer 4y ago
    Again, what if there is no static declaration? impl Foo { // static fn foo() {} } Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous.
    - deleted 4y ago
      [deleted]
    - masklinn 4y ago
      > Again, what if there is no static declaration? So your suggestion is to remove static methods from the language? > Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous. Detect what case? There is a dozen and eventually an infinite number of potential instance call ABIs. And the Rust compiler is generally very much on the “refuse to guess” side of the fence (hence no global type inference), so you have to tell it what it should expect, `self`, `&mut self`, and `&self` have rather different requirements, impacts, and capabilities to say nothing of the rest.
  - phaylon 4y ago
    Small nitpick: Fortunately, `Rc` and `Arc` actually don't require the nightly feature.

nevi-me 4y ago

I prefer self. The changes in ES5 in JavaScript were painful because some people kept losing track of `this`'s scope. IIRC it changed with arrow functions, making it hard to know what `this` the code was using. I prefer an explicit `this` or `self` being passed, so that I know where it's defined. Something close enough, Kotlin uses `it` in lambdas. If you're nesting your lambdas, it can be tricky to review the code when just staring at it (when the IDE isn't helping you with types).

nneonneo 4y ago

Also, there are several different ways to pass self: `self`, `mut self`, `&self`, `&mut self`, and they have very different semantics. Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. but I feel like the explicit `self` is very clear and easy to understand.

masklinn 4y ago
> Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. `fn Box foo()`? `fn Arc foo()`? It also requires more parser lookahead. The `mut` case is also very odd, as it's not part of the function API (it just configures the binding of the internal local). Plus if self was implicit it likely would need to be a keyword, so that wouldn't be a usecase at all anymore.
- pkolaczk 4y ago
  IMHO that would be a dead end. I prefer passing self explicitly and I still hope it will be possible to bind self partially in the future, e.g bind only one field. Currently if you call a function that e.g returns a reference to a field, the compiler borrows the whole self, not the field. So partial borrows are supported partially : they can't cross function boundaries.
  - masklinn 4y ago
    Yeah partial borrows are not part of the file system, which makes a lot of sense as it would severely leak implementation details. I regularly get frustrated but I don’t really see an easy alternative, it’s be a lot of work having it work let alone contextually (e.g. from pub functions for pub fields but not for private types / fields), and how would you even express the borrows / holes?

optymizer 4y ago

what if there's no static function with that name?

masklinn 4y ago
There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box<Self>) {} } impl Foo { // instance, refcounted fn foo(self: Rc<Self>) {} }
- optymizer 4y ago
  Again, what if there is no static declaration? impl Foo { // static fn foo() {} } Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous.
  - deleted 4y ago
    [deleted]
  - masklinn 4y ago
    > Again, what if there is no static declaration? So your suggestion is to remove static methods from the language? > Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous. Detect what case? There is a dozen and eventually an infinite number of potential instance call ABIs. And the Rust compiler is generally very much on the “refuse to guess” side of the fence (hence no global type inference), so you have to tell it what it should expect, `self`, `&mut self`, and `&self` have rather different requirements, impacts, and capabilities to say nothing of the rest.
- phaylon 4y ago
  Small nitpick: Fortunately, `Rc` and `Arc` actually don't require the nightly feature.