Multiple argument lists instead of [me: Self] in deduced list

[jens-auer]

What is the definition of the deduced parameter list of functions? The grammar in Functions does not specify the deduced parameter list as it is introduced with Generics. Here, the example only contain types, but there is the definition of member functions using the [me: Self] parameter that indicates that values (in that case runtime values) would be allowed. So I tried to define a member function that just uses another name than "me", but this does not compile:

package sample api;

class A {
    fn foo[me: Self]() {}
    fn foo2[ich: Self]() {}
}

COMPILATION ERROR: :5: illegal binding pattern in implicit parameter list
Compiler returned: 1

I then thought to try something that could be deduced from a constant context, but this also does not compile

class V(T:! Type, n: i32) {

}

fn size_t[T:! Type, n: i32](x: V(T, n)) -> i32 {
  return n;
}

fn Main() -> i32 {
  let v: V(i32, 2) = {};
  return size_t(v);
}

I am wondering what constraints are placed on the deduced parameter list. From its name, I would expect only information that can be deduced at compile time, but this would rule out the current object.

The actual reason I am asking this is because I found the extra parameter list with [me: Self] quite odd. I would find it more natural to allow multiple parameter lists like in Scala, and restrict the deduced parameter list to information that can be deduced at compile time, i.e. types and constants. I think this would allow a more consistent syntax in the form of

class A {
    fn foo[Self:! A](me: Self)() {}
}

A member function can then be defined as a function that has at least two parameter lists where the first list only contains a single parameter either constrained to the class, the class itself or a corresponding addr type.

At the same time it would generalize very well into a generic concept that can be used for other use cases, e.g. to supply context information by implicit parameters as in Scala (maybe in a restricted form to prevent the abundant abuse ...) - a common use case would be to provide executors for async libraries.

I realize the syntax is a bit lengthy for every member function, but I am pretty sure that a convenient and shorter syntax can be found.

[geoffromer]

Yeah, this is pretty confusing. The current rule is that the deduced parameter list consists of two things: parameters whose values are deduced from the ordinary parameters, and the me parameter (which is identified by the fact that it is spelled using the me keyword). They don't have much in common other than the fact that they bind to arguments that don't appear inside the parentheses of a function call. See p0722 for some of the history and reasoning behind this design.

I think it might make sense to revisit this decision -- we're getting new information about how confusing this syntax is, and I'm not sure if we ever fully considered an alternative like the one you suggest (@jsiek has subsequently suggested something similar, but I'm not sure if he ever turned it into a proposal).