Please explain why are these expressions disallowed in lambda predicates

[danim-hub]

Type of issue

Missing information

Description

The text states that:

because allowing them would create a breaking change in all libraries that parse expression trees.

I understand that, but the article does not explain why libraries had not been updated.
Which libraries are those? Are they parts of .NET that are still pending to update, or are there some third party libraries? I am pretty much sure that libraries running on newer C# versions have probably been updated to support these lambdas. Or that you could have the predicates allowing ?. in newer versions and have new libraries allow that.

All these questions could be solved by indicating the libraries that need updating. If you want to avoid offending 3d party libs developers, you could just link to a relevant SO.

This feedback is not about "fixing" or allowing these constructs. Is about understanding the rationale behind these restrictions

[Enter feedback here]

Page URL

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/expression-tree-restrictions

Content source URL

https://github.com/dotnet/docs/blob/main/docs/csharp/language-reference/compiler-messages/expression-tree-restrictions.md

Document Version Independent Id

65ff7e4c-3e13-644f-f8bd-06f015fd5e56

Platform Id

bb276530-3f49-d351-faaf-f5955e642fc0

Article author

@BillWagner

Metadata

• ID: 25fc34a8-5b97-e672-c99e-409db63b4179
• PlatformId: bb276530-3f49-d351-faaf-f5955e642fc0
• Service: dotnet-csharp
• Sub-service: errors-warnings

Related Issues

[BillWagner]

Hi @danim-hub

I'll add @jaredpar and @phil-allen-msft for their thoughts as well.

The text is brief, but accurate: Adding more expression types to expression trees could potentially break any library that parses those trees. It's an insidious type of break because the compiler wouldn't issue any diagnostics to help diagnose the problem. Any application that depends on a library that parses expression trees would just stop working at runtime when any of these new expressions appeared in source for the app.

C# LDM has a high bar for accepting breaking changes. In fact, we work hard to design new features that are expressed in ways that enhance backwards compatibility. For example, the new extension operators are compiled to constructs that can be expressed in expression trees for most operators: https://learn.microsoft.com/dotnet/csharp/language-reference/proposals/csharp-14.0/extension-operators#use-of-extension-operators-in-linq-expression-trees.

In general, the dotnet/csharplang repository is where the why around designs are discussed. I don't want to add a detailed design discussion, especially in an article on compiler diagnostics. The only practical fix for these errors is to write the expressions so they don't use the invalid expression types.