Improve method syntax

[emlai]

Currently methods require annotating both the receiver name (self) and the receiver type (Self or Self*), and require this to be done in a separate section delimited by square brackets (I'm using self instead of me in these examples as it's likely to be replaced: #1382):

class Circle {
  fn Diameter[self: Self]() -> f32 {
    return self.radius * 2;
  }
  fn Expand[addr self: Self*](distance: f32) {
    self->radius += distance;
  }
}

To reduce the amount of redundancy and boilerplate and to make it simpler and more familiar to users of existing languages, a couple of changes can be made:

• Move the receiver declaration from the square brackets into the normal parameter list (it is fundamentally just an additional parameter anyway, and languages such as Rust and Python already do it like this).
• Remove the explicit self name from the declaration since it's the same for every method. (Of course, inside the method, referring to the receiver would still happen with self. self could become a keyword to aid this.)
• Change the Self type to lowercase self keyword that means both the receiver type and the receiver value.
• Remove the addr. self* already means the receiver is passed by pointer.

With these changes the above code would look like this:

class Circle {
  fn Diameter(self) -> f32 {
    return self.radius * 2;
  }
  fn Expand(self*, distance: f32) {
    self->radius += distance;
  }
}

Alternatively, if we want to be more familiar to C++ users, we could do like Swift: remove the explicit self parameter, use static (or class) keyword for class functions, and mutating keyword for methods taking self by pointer, and no additional keyword for non-mutating methods:

class Circle {
  static fn Unit() -> Self {
    return {.center = Point.Origin(), .radius = 1};
  }
  fn Diameter() -> f32 {
    return self.radius * 2;
  }
  mutating fn Expand(distance: f32) {
    self->radius += distance;
  }
}

These are just suggestions, there are other possible variations as well. Let me know your thoughts.

I might expand this post later to address the decisions in p0722 that lead to the current design, but what it mostly boils down to is: simple things should have simple syntax, reserve the more complicated syntax for advanced use cases. No one wants to write [addr self: Self*] over and over again.

---

If, however, we only intend to provide methods for C++ compatibility, and want to discourage users from using them in pure-Carbon code, then it might make sense to require the current boilerplatey syntax.

[0xBLCKLPTN]

Now change fn to def and we have half a python ;)

But, such changes simplify code writing and readability

[FGUFA]

Maybe an outside view from someone just getting into touch with Carbon. This method syntax was the very first thing that struck me as a step back from C++ actually. So I'm happy to see this is a topic of discussion.

Whether something is a function, a mutating method or a const method is something very fundamental, both when writing code and when reading APIs. Something that should have "first level" support by the language.

In Carbon, I just get the feeling that methods (as opposed to functions) are somehow second-level citizens. You start with functions (fn) by default. They are quick and easy to write and read. But if you want a method, you have to start with a function and then add some seemingly boilerplate code in some off-looking brackets. And if you want a mutating method, you have to add even more boilerplate code. Which actually becomes somewhat low-level: "In order to get a mutating method, you have to take self by address instead of by value."

As a developer, I would much prefer to state the higher-level intent at this point. Ideally in some short, concise form, at an easy to spot location.

Which is why something like mutating fn, const fn, or static fn would be the much more "natural" choice to me (or even some top-level alternative keywords to fn instead of applying modifiers).

[masters3d]

Swift is trying to add explicit self annotation to methods so it can hang attributes to self.
https://forums.swift.org/t/optional-explicit-self-parameter-declaration-in-methods/59522

[vbregier]

I like the idea to move self parameter inside parens instead of square brackets, it does not make sense for me to have it inside square brackets.

I do not like the idea of self keyword meaning two things (receiver, and its type). This is confusing. A keyword should mean a single thing.
I do not feel we need a keyword for the receiver, why not accept any name, and let programmer choose to use self, this, or any other name ?

For me it is not a big deal to have to write self: Self or self: Self * over and over, and it would make the language simpler to just use first parameter for receiver.