-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a cached delegate for method group conversion #5835
Comments
WOO HOO!!! |
Isn't this a breaking change? I don't think I've ever written code that cares about delegate identity (as opposed to equality), but if it anybody has, this could break it. Also, it used to be that you got crazy compiler magic if you used the Now, the rule is to be that the crazy compiler magic happens unless you say I guess this is mostly harmless, so long as you do not also break the equality semantics of the delegates produced, and so long as you can turn this off with the |
Yes please. Can we do something about delegates in generic methods? Currently they are still a much slower caching (if they get cached at all) strategy then for delegates created in non-generic methods |
👍 for this, also as per the comment by @mburbea is there any interest in caching for delegates in generic methods? Is it worth creating a separate issue for it. |
Roslyn already does this. For example, with this code: using System;
public class Test
{
public static void Main() { GenericMethod<string>(); }
private static void GenericMethod<T>()
{
InvokeAction(() => Console.WriteLine(typeof(T)));
}
private static void InvokeAction(Action action)
{
action();
}
} the code generated for
|
Oh sweet, I did verify the IL but forgot I wasn't using Roslyn yet at work! |
So what you're saying is the compiler should handle the insanity that was DotNetAnalyzers/StyleCopAnalyzers#1689? I'm totally in agreement there. 👍 |
That allocation is once per application (not per request) so its's not a big deal. |
Right @davidfowl this is done in startup and then cached internally, I failed to think that far ahead. |
Any news? Seems to me more and more people stumble upon this. |
The spec has already been modified and published. ECMA-334 (C# Language Specification) 4th edition (June 2006) disallows caching:
ECMA-334 5th edition (December 2017) allows caching:
Also available in dotnet/csharpstandard. |
This is resolved by #58288. Expected to ship in 17.2. I believe the caching behavior only occurs when using a preview language version, and probably with C# 11/.NET 7 and up once they are released. |
FYI, feature was merged for Visual Studio 17.2 preview 2 as preview feature. Will be released as part of .NET 7 and C# 11 by end of year. |
The method group conversion today always creates a fresh delegate instance.
Instead, for a method group conversion from a static method we should cache it and only create it once, like we do for non-capturing lambda expressions.
[The C# language spec is being modified to permit this]
The text was updated successfully, but these errors were encountered: