You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In short, delegates are all different types according to the CLR and they are incompatible with each other even if their signature matches. The C# language has no special knowledge of any specific delegate types, including the Func<...> or Action<...> delegate families. If lambda inference were to decide to use Func<...>, assuming that could be done unambiguously, assigning that to a variable or parameter of a different-but-compatible signature would involve wrapping the delegate with another delegate. That doubles the overhead when invoking the delegate, each call costing about the same as a virtual instance method call, which isn't a lot but can add up in aggregate.
I still think this is worth reconsidering, especially if collection literals are on the table, because they will also have to somewhat arbitrarily target clandestine types that are conventionally used.
If lambda inference were to decide to use Func<...>, assuming that could be done unambiguously, assigning that to a variable or parameter of a different-but-compatible signature would involve wrapping the delegate with another delegate.
But isn't the suggestion here to only use Func<....> when it would otherwise be an error?
Expected Behavior:
Actual Behavior:
The text was updated successfully, but these errors were encountered: