Discussion: static local functions and implicit parameters

[alrz]

In order to make a static local function we need to explicitly pass all intended captures as arguments and declare a parameter for each,

{
  LocalFunction(this, parameter, local);
  static void LocalFunction(LongSelfTypeName self, AnotherType parameter, YetAnotherType local)
    => Use(self, parameter, local);
}

We could simplify the above to the following, using parameter list as a kind of "capture list"

  LocalFunction();
  static void LocalFunction(this, parameter, local)
    => Use(this, parameter, local);

At the point of invocation all arguments must be fully assigned and in the scope.

Each argument declares a parameter with the same name. For this, we use @this for the name (in metadata and if used with named args) but we still can use this to refer to that parameter.

  static void LocalFunction(this, parameter, local)
    => LocalFunction(@this: this, parameter: parameter, local: local);

An advantage of using this is that we could possibly permit an impilcit this reference in the body.

  static void LocalFunction(this)
    => InstanceMethod(); // this.InstanceMethod();

These parameters act like optional parameters which default to a location with the specified name, therefore they should always come after explicit parameters.

  LocalFunction(arg); // `local`, `param`, `this` are passed implicitly
  static void LocalFunction(C additionalArg, local, param, this)
  {
    LocalFunction(additional, some, other); // `this` is passed implicitly
    LocalFunction(additional, @this: this.Next); // `local`, `param` are passed implicitly
  }

In this case, we need to define most unchanging values as the rightmost parameters for them to be passed implicitly everywhere. For instance, this should always come last.

[svick]

Wouldn't this be confusing when it comes to mutating such variables?

Currently, there are two ways to share values between a local function and its parent:

1. Using captures. This is implicit (no visible syntax) and the variables are shared. This means that mutating a variable in the local function affects the parent.
2. Using parameters. This is explicit (you have to actually write some code at the call site) and the variables are separate by default (you can use ref to share the variables). This means that mutating a variable in the local function does not affect the parent.

This would add a third way, one which is implicit, but makes the variables separate and that feels inconsistent to me.

In code:

int i;

void F1() => i++;
i = 0;
F1();
Console.WriteLine(i); // 1, as expected

void F2(int i) => i++;
i = 0;
F2(i);
Console.WriteLine(i); // 0, as expected

void F3(ref int i) => i++;
i = 0;
F3(ref i);
Console.WriteLine(i); // 1, as expected

void F4(i) => i++;
i = 0;
F4();
Console.WriteLine(i); // 0 ???

Though making the variables shared could require a capture object, which is exactly what you're trying to avoid. And I can't think of another reasonable way to decrease the confusion either.

[alrz]

void F4(i) => i++;
i = 0;
F4();
Console.WriteLine(i); // 0 ???

I expect this to print 1. Variables are passed as-is at the point of invocation, they are not captured at declaration-site. Meaning that the F4(); call lowers to F4(i).

You can think of it as the same way optional parameters behave, where the default value is inserted at the call-site if absent.

[alrz]

Oh I guess now I see what you mean. I think the only way to prevent that is to make all implicit parameters readonly.

Perhaps we could permit static void F(ref i) for byref implicit parameters and only allow mutations for those.