Discussion: Inferred "Quantum" Lambdas

[HaloFour]

Lambda expressions are currently not supported for local variable inference. This is because the signature of the lambda expression does not indicate the type of the delegate which is necessary to create an instance of that delegate type.

What if the compiler didn't have to actually know the delegate type at the time that the variable is declared? What if the variable could have a form of "pseudo-type" based on its signature and the compiler could "collapse the wave function", as it were (hence the name), at the point that the instance needed to be converted to a delegate?

Here's an example with captures, which isn't very different:

public void M(bool b, int x) {
    var f = (int y) => x == y;
    if (b) {
        M1(f);
    }
    else {
        M2(f);
    }
}

public void M1(Func<int, bool> f) { }
public void M2(Predicate<int> p) { }

// under the hood

[CompilerGenerated]
private class $DisplayClass {
    public int x;

    public bool $M(int y) {
         return x == y;
    }
}

public void M(bool b, int x) {
    var displayClass = new $DisplayClass();
    displayClass.x = x;
    if (b) {
        Func<int, bool> $temp1 = displayClass.$M;
        M1($temp1);
    }
    else {
        Predicate<int> $temp2 = displayClass.$M;
        M2($temp2);
    }
}

Here's an example without captures:

public void M(bool b) {
    var f = (int y) => x % 2 == 0;
    if (b) {
        M1(f);
    }
    else {
        M2(f);
    }
}

public void M1(Func<int, bool> f) { }
public void M2(Predicate<int> p) { }

// under the hood

[Serializable]
[CompilerGenerated]
private sealed class $C {
    public static readonly $C _c = new $C();

    public static Predicate<int> _p;
    public static Func<int, bool> _f;

    internal bool $M(int x) {
        return x % 2 == 0;
    }
}

public void M(bool b) {
    if (b) {
        Predicate<int> $temp1 = $C._p ?? ($C._p = $C._c.$M);
        M1($temp1);
    }
    else {
        Func<int, bool> $temp2 = $C._f ?? ($C._f = $C._c.$M);
        M2($temp2);
    }
}

Advantages:

1. Inferred local variables for lambda expressions
2. Marginally less verbose
3. Avoiding the double-delegate invocation if trying to pass to multiple functions accepting different but compatible delegates

Disadvantages:

1. An additional allocation for every delegate type that the lambda is "collapsed" to, although this is already unavoidable
2. The variable is some weird pseudo-type which makes it unusable in other contexts, e.g. f.GetType().
3. This is similar to using local functions as the delegate target

While typing this up I believe I've come to the conclusion that it's not a terribly good idea. But whatever, tear it up folks!

[bbarry]

I like your unspeakable types notation. $DisplayClass is easier to type than something like <>t__M__DisplayClass and almost doesn't break github markdown syntax highlighting.

[HaloFour]

@bbarry Not to mention you can read it without trying to pick the dots out of a wall of angle brackets and underscores.

[agocke]

I believe C++ does something similar with auto and both lambdas and array literals and oh-my-god is it frustrating. I think there's another proposal for assuming a default type (Func/Action or maybe we could introduce a "real" function type into the language) which IMHO is a much better experience.

Trying to get a literal to target-type to the appropriate thing is hard enough when the literal is actually inline, but when it's in a variable you end up with "spooky action at a distance" (to continue the quantum superposition metaphor 😉).

[HaloFour]

@agocke

I think there's another proposal for assuming a default type

I largely agree. The only problem with those assumptions is that Func<...>/Action<...> only work for the simplest kinds of delegates. Toss in a ref parameter and the compiler could no longer infer the delegate type. You also have the issue where if you assign the lambda to an inferred local and then pass that to a method expecting some other kind of delegate that you end up with another allocation and additional overhead on invocation. Not that I think that either of these problems would be show-stoppers.

[agocke]

I think the cleanest solution would be inferring a native function type: var f = x => x; infers a type of T -> T. Then there would be conversions to delegate types. The problem, of course, is in the details. I'm not sure there's any off-the-shelf inference algorithm that will be compatible with C#'s overload resolution rules. If someone wants to take a stab at adapting Damas-Milner for C# conversion rules, that would be great.

[bondsbw]

Internally there would need to be a more generalized concept of lambdas than exists today (int -> bool) which is convertible to any compatible delegate type.

In that case, why not expose it somehow?

lambda(int => bool) f = (int y) => x == y;

Then (perhaps) you could return it, pass it as a parameter, declare it as a field, etc.

[agocke]

If you have to write the type, the point is lost anyway. Someone still needs to work out the inference algorithm.

[bondsbw]

That could be true for any var. Granted this one is definitely more complex.

(Edit... I say it is more complex, but I'm not sure I really believe it. The inferred type of var would always be a lambda(...). The target-typed conversion would be the complex part, but is it really that hard?)

[bondsbw]

If we really don't want a new keyword:

delegate(int => bool) f = (int y) => x == y;

[bbarry]

@bondsbw what about Expression<Func<int, bool>>

[bondsbw]

@bbarry Like Func<int, bool> you wouldn't have the ability to declare ref parameters.

(assuming you meant Expression<Func<int, bool>>)

[bbarry]

yes (edited)

I mean delegate(int => bool) f seems to imply that the f variable is denoting a compiled lambda expression. What I suspect people who want var f = y => x == y; desire is something like "declare f as a lambda matching this thing however it winds up getting used..."

I'd propose to do exactly that:

the declaration_statement consisting of

'var' identifier '=' lambda_expression ';'

could simply exist and be inlined by the compiler wherever that identifer exists in scope (edit: as @agocke implies there is a devil here in identifying type information within this statement).

(not actually suggesting this, I personally think this proposal is of very little value)

[bondsbw]

What I suspect people who want var f = y => x == y; desire is something like "declare f as a lambda matching this thing however it winds up getting used..."

That's precisely what delegate(int => bool) f does.

[bondsbw]

An Expression could be rendered downstream once it is converted.

[bbarry]

Why should there be any additional syntax then for that?

Why not merely relax the language from:

• The initializer expression must have a compile-time type.

to:

• The initializer expression must have a compile-time type or be a lambda_expression.

and then add something like:

If the initializer expression is a lambda_expression, the following process is invoked:

1. Let the identifier be v
2. where the variable v is used in scope, determine type of variable. It is an error if the type cannot be determined.
3. for each unique usage type, replace the variable v with a generated id and duplicate the declaration_statement with the new type and reparse.

[HaloFour]

@Neme12

Well, they are older... that's just a fact of reality 😄

Many of my delegates are quite a bit younger than Action<...> or Func<...>, thanks. :P

[bondsbw]

@CyrusNajmabadi

We just imbue the language with knowledge of Func/Action, and we make it pretty simple to provide shorthand literals for those most common of delegate types.

What does this really buy over imbuing the language with knowledge of the underlying method group?

[CyrusNajmabadi]

What does this really buy over imbuing the language with knowledge of the underlying method group?

it would be much simpler to provide, for one.

[CyrusNajmabadi]

I disagree with the notion that delegate types are somehow "older" or "legacy". I continue to use them for all but the simplest cases as being nominal with proper parameters makes them self-documenting, plus I can slap XML docs on them. I also frequently use them for injected dependencies where an interface/implementation would be overkill.

The question is not if they're used or not. The question is: is there enough value from just getting Func/Action working as to make this 'good enough'. IMO, i think it would. For the other cases, you can still do what you do today. i.e. using a local function, or just using a named-type when supplying the lambda.

---

Note: i completely agree the quantum-lambda approach is more powerful and would handle more scenarios. But i also think it's less likely to happen, and the power it provides isn't worth the cost. So i'm reproposing narrowing things down to something that would be quite easy to provider, and which which would support many scenarios.

Also, note that my suggestion doesn't not eliminate the possibility of doing quantum lambdas. Indeed, they are complimentary.

[bondsbw]

@CyrusNajmabadi

Also, note that my suggestion doesn't not eliminate the possibility of doing quantum lambdas. Indeed, they are complimentary.

If var f is resolved to Func<int, bool> in C# v.X, wouldn't it prohibit changing the definition in v.X+1 to resolve f to the method group?

[Neme12]

I continue to use them for all but the simplest cases as being nominal with proper parameters makes them self-documenting, plus I can slap XML docs on them.

I agree. For one thing, Predicate reads better than the word "func". But putting that aside, I can see why it's nice to name the delegate sometimes and especially name the arguments or even provide a doc.

I think in an ideal world, there would be first-class function types, and if you wanted to name them, you would use global type-aliases. But they'd still be compatible. And many times, you wouldn't even need that as much if these function types had optional names similar tu tuples... What a nice dream 😄

[CyrusNajmabadi]

If var f is resolved to Func<int, bool> in C# v.X, wouldn't it prohibit changing the definition in v.X+1 to resolve f to the method group?

'var f' woudl be resolved to Func<int, bool> if you actually wrote: var f = (bool x) => .... So i don't see how method-groups actually come into consideration here.

[bondsbw]

@Makeloft Check what you quoted. Your solution forces a delegate type, which this proposal is trying to avoid.

[tannergooding]

The comments from ghost have been hidden as spam. They are coming from a user who was previously banned and who is currently trying to circumvent their ban.

As a general note: Repeatedly advertising your own repository as a solution to most language proposals, after being warned, is deemed to be "unprofessional conduct"; as is attempting to circumvent a ban.

The Code of Conduct is expected to be followed by all contributors/posters to The dotnet organization on GitHub. For more details, please see: https://dotnetfoundation.org/code-of-conduct

[Thaina]

I think lambda should be quantum and anonymous all along. It was a mistake to have it must be typed when it could have duplicate signature

We should starting to deprecate the old delegate system

[Rekkonnect]

The only problem I see with this is the confusion of var in this context. var could imply that the target type is inferred, but our purpose is not binding the exact delegate type, probably ever. The only information we want to extract from the lambda expression (or method group) is its arguments and return types, basically the signatures. In this case, new syntax should probably be introduced.

What I would be in favor of is <keyword> var <identifier> = <expression>, where <keyword> should be a keyword for this exact purpose and the grammar mandates that both the keyword and var be used for this scenario.

The only options I could make sense with:

• delegate var, which I find a bit too verbose
• partial var, with partial meaning "partially bound delegate type"
• free var, with free meaning "freely bound delegate type"

I'm pretty sure there can be a better idea for that keyword in question.

[HaloFour]

IMO var would be appropriate here, and the inferred type would be the natural lambda type, which would be implicitly convertible to any delegate type with a compatible signature. The behavior of the compiler would effectively be the same as if the inferred type was an unspeakable synthetic delegate except that the compiler could optimize around not actually emitting the synthetic type or converting between delegate types.

[Rekkonnect]

That's a view I hadn't considered, and I'm fully supportive. This essentially enables usage of var for lambda expression assignments in all contexts, to which I say "why not already done?"

[333fred]

var for lambdas is about to have a real meaning in C# 10. We almost certainly won't accept a different interpretation in a future version.

[HaloFour]

Indeed, I think the natural type feature for lambda will preclude this proposal. I'm hopeful that future features that may enable signature equivalence in delegates combined with natural lambda types will effectively provide the same benefits, though.

[RikkiGibson]

#1694 (reply in thread)

Indeed, I think the natural type feature for lambda will preclude this proposal. I'm hopeful that future features that may enable signature equivalence in delegates combined with natural lambda types will effectively provide the same benefits, though.