Placement of parameters for methods makes generic methods awkward

[dpcollins-google]

So when you have an instance method, what differentiates it from a static method is that it accepts as an implicit parameter in the [] block a value of type Self:

class Point {
  // Method defined inline
  fn Distance[me: Self](x2: i32, y2: i32) -> f32 {
    var dx: i32 = x2 - me.x;
    var dy: i32 = y2 - me.y;
    return Math.Sqrt(dx * dx - dy * dy);
  }
...
}

However, Self is already a keyword for (as far as I can tell) "the type of this object", so why are methods not just defined as functions having the first parameter be Self, possibly const qualified, possibly pointer qualified?

In particular, the current design makes it very confusing to me where I would add a generic parameter. For example, lets assume I wanted to get the Distance to any object that implements Pointlike defined as:

interface Pointlike {
  fn x() -> i32;
  fn y() -> i32;
}

How would I write that method with the current syntax?

[geoffromer]

So when you have an instance method, what differentiates it from a static method is that it accepts as an implicit parameter in the [] block a value of type Self:

class Point {
  // Method defined inline
  fn Distance[me: Self](x2: i32, y2: i32) -> f32 {
    var dx: i32 = x2 - me.x;
    var dy: i32 = y2 - me.y;
    return Math.Sqrt(dx * dx - dy * dy);
  }
...
}

However, Self is already a keyword for (as far as I can tell) "the type of this object", so why are methods not just defined as functions having the first parameter be Self, possibly const qualified, possibly pointer qualified?

Self is a keyword for "the type that this function is defined as a member of", so that wouldn't give us a way to distinguish methods from member functions that happen to take Self as their first parameter. In principle we could use me to disambiguate as you describe, since that's a keyword that means "the object that this method was called as a member of", but we didn't want to do that because it creates a mismatch between the parenthesized parameters in the method definition and the parenthesized arguments at the callsite.

In particular, the current design makes it very confusing to me where I would add a generic parameter. For example, lets assume I wanted to get the Distance to any object that implements Pointlike defined as:

interface Pointlike {
  fn x() -> i32;
  fn y() -> i32;
}

How would I write that method with the current syntax?

It depends on what you want that method to be a member of. If it's a member of Pointlike, it can be written as an ordinary method:

interface Pointlike {
  fn x[me: Self]() -> i32;
  fn y[me:Self]() -> i32;

  fn Distance[me:Self]() -> i32 {
    // Implementation goes here
  }
}

(I also added [me: Self] to your declarations of x and y, because I assume you want them to be methods). You can prefix that method declaration with default if you want types to be able to override the implementation.

If you want Distance to be a method of some other interface (e.g. if you don't control Pointlike), I think you'd need to use a blanket impl.

[vbregier]

Self is a keyword for "the type that this function is defined as a member of", so that wouldn't give us a way to distinguish methods from member functions that happen to take Self as their first parameter.

I do not think this is a problem. Instead of trying to distinguish between the two, they could be considered as the same concept, which is allowed to be called both ways.

So
var p: PointLike = ...; return p.x();

would be strictly equivalent to

var p: PointLike = ...; return PointLike::x(p);

(this is what python does, as far as I know. method syntax is just syntactic sugar)

This makes the language overall simpler, as there is now one fewer concepts. Methods are just functions.