How is the type of me restricted, and where can methods be declared?

[zygoloid]

In #1122 it was observed that we currently don't restrict the type of me nor where methods can be declared, and this leads to support for a form of extension method-like functionality.

We should decide if that's what we want, and if not, what restrictions we'd like in place instead.

[chandlerc]

I don't have any problems with the direction of #1122.

For me, the issue is that while #1122 provides a very nice way to address the technical challenges of extension methods, the result is somewhat unergonomic and it isn't clear that the convenience provided is worth that ergonomic burden.

Currently, I feel like this isn't sufficiently motivated to include, but I'm pretty open to revisiting this if/when we get a good motivation for doing so.

So I would suggest that we restrict using me parameters to contexts where there exists some path for use with simple member access. I think that's classes, interfaces, impls, and probably a few other contexts I'm not thinking of.

Does that seem like a workable initial stance?

[chandlerc]

Adding a bit more nuance and precision after a discussion with @zygoloid here...

The set of scopes where we should allow me parameters are the same set of scopes which can be searched by some form of simple member access. We currently think that this is every scope except for namespaces and function scopes, but the goal should be that this matches and tracks the scopes searched by simple member access.

Similarly, these are also the scopes where it might be reasonable for us to mark functions without a me parameter with a special keyword or marker, as we expect a method to be a reasonable default within those scopes. But we're not suggesting that change here, just trying to keep the sets the same.

We'd be happy to have a restriction on the type of the parameter as well, but it doesn't seem essential and might be hard to get right in practice. My suggestion was that the type should be a valid parameter type (after some sequence of implicit conversions) for an object that would trigger simple member name lookup into the scope of the function. But it isn't clear we can model or check this easily or at the time of declaration, and that seems OK. Put differently, restricting the type (at declaration time) seems like it might be useful to help catch mistakes more than a necessary part of type checking the program.