Skip to content
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

explicit lambda return type behavior with covariant delegates #73319

Closed
alrz opened this issue May 3, 2024 · 3 comments
Closed

explicit lambda return type behavior with covariant delegates #73319

alrz opened this issue May 3, 2024 · 3 comments
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@alrz
Copy link
Member

alrz commented May 3, 2024

I think as long as the delegate is covariant this should work since an indirect assignment of the same expression is valid.

// ok
Func<object> a1 = () => "";
        
// unexpected error
Func<object> b1 = string () => "";
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels May 3, 2024
@CyrusNajmabadi
Copy link
Member

Definitely an interesting case! Would have to see how the spec works here. but i soemwhat agree. This feels like it should fall out from lambda return types and variance. i wonder if there's some rule preventing this, or if ti's an accidental compiler bug.

@jaredpar
Copy link
Member

@cston is this "by design"? Not sure it's going to meet the bar for fixing right now but curious as to the intent.

@cston
Copy link
Member

cston commented May 20, 2024

Variance is not supported for an explicit lambda return type in the anonymous function conversion: see Explicit return type.

Variance conversions are not allowed from lambda return type to delegate return type (matching similar behavior for parameter types).

That matches the conversion requirement for lambdas with explicitly-typed parameters: see 10.7 Anonymous function conversions.

  • If F has an explicitly typed parameter list, each parameter in D has the same modifiers as the corresponding parameter in F and an identity conversion exists between the corresponding parameter in F.

Parameter example: see sharplab.io

Action<string> a1 = (object o) => { }; // error CS1661: ... parameter types do not match

Action<object> a2 = (object o) => { };

@jaredpar jaredpar closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

No branches or pull requests

4 participants