Audit by Deep Research

Audit of StyleCopAnalyzers for C# 10 Lambda Natural Types Support

This note summarizes how C# 10 lambda natural types (attributes, explicit return types, etc.) interact with existing StyleCopAnalyzers rules, and what needs to change (implementation, docs, tests) so lambdas are fully supported in their new roles.

Impacted rules:

SA1008 – Opening Parenthesis Must Be Spaced Correctly
SA1121 – UseBuiltInTypeAlias
SA1125 – UseShorthandForNullableTypes
SA1130 – UseLambdaSyntax
SA1141 – UseTupleSyntax
SA1410 – RemoveDelegateParenthesisWhenPossible

Other rules were reviewed and are either already compatible or unaffected.

SA1008 – Opening Parenthesis Must Be Spaced Correctly

Purpose

Ensures correct spacing around an opening parenthesis in C#:

Normally no space before ( (except after certain keywords/operators).
Normally no space after (, unless it’s at the end of a line.

C# 10 interaction (lambda attributes)

With C# 10, lambdas can have attribute lists:

var f = [Attr] () => { };

This introduces the pattern ] ( (closing ] from an attribute list immediately followed by ( for the parameter list). SA1008 has to decide whether that space is allowed:

Historically, ] ( would be treated like “space before (” and could be flagged.
For attribute-on-lambda style, we likely want to allow [Attr] () and disallow [Attr](), or at least pick one style and enforce it consistently.

Required changes

Implementation

Update the spacing logic so that when an opening parenthesis belongs to a lambda parameter list that immediately follows an attribute list:
- A single space between ] and ( (i.e. [Attr] ()) is allowed (and likely preferred).
- The no-space variant [Attr]() is treated according to the chosen convention (most likely as a spacing violation).
Documentation

Clarify how SA1008 applies when an attribute immediately precedes a lambda’s parameter list:
- Call out that a single space between the closing ] and ( for a lambda is permitted (or required).

Tests

Add tests such as:

var f = [Attr](x) => { };   // expect SA1008 if space is required
var f = [Attr] (x) => { };  // no diagnostic

Include multi-line variants and multiple attributes to ensure consistent behavior.

SA1121 – UseBuiltInTypeAlias

Purpose

Requires the use of built-in aliases (int, string, etc.) instead of BCL names like Int32, String, or System.Int32.

C# 10 interaction (explicit lambda return type)

C# 10 allows lambdas with explicit return types:

var func = Int32 (int x) => x;
var func2 = System.Int32 (int x) => x;

SA1121 should treat the explicit return type of the lambda exactly like any other type usage and prefer int.

Required changes

Implementation

Extend SA1121 to inspect explicit lambda return types:
- Analyze ParenthesizedLambdaExpressionSyntax nodes that include a return type.
- Run the same checks for Int32, System.Int32, etc. in that return type as it already does in other type positions.
Documentation

Existing description already claims to cover “anywhere in code”; optionally:
- Add a note that this explicitly includes lambda signatures introduced in C# 10.

Tests

New tests for lambdas like:

var f = System.Boolean (int x) => true;
var g = Int32 (Int32 x) => x;

expecting SA1121 diagnostics and code fixes that convert to:

var f = bool (int x) => true;
var g = int (int x) => x;

Include tests for both return type and parameter types in lambdas.

SA1125 – UseShorthandForNullableTypes

Purpose

Prefers the T? shorthand instead of Nullable<T> or System.Nullable<T>.

C# 10 interaction (nullable in lambda signatures)

Explicit lambda types can include nullable types, e.g.:

var f = Nullable<int> () => 0;
var g = (Nullable<int> x) => 0;
var h = System.Nullable<int> (int x) => 0;

These should be treated like any other usage of Nullable<T> and be replaced with int?.

Required changes

Implementation

Extend SA1125 so that it checks:
- GenericNameSyntax in lambda parameter lists, and
- explicit lambda return types.
Use the same logic as for methods: Nullable<T> and System.Nullable<T> in these positions should be flagged and converted to T?.
Documentation

The rule already states it applies whenever Nullable<T> is used. Optionally:
- Add a note that this includes lambda expressions with explicit types.

Tests

Add scenarios like:

var f = Nullable<int> () => 0;
var g = (Nullable<int> x) => 0;
var h = (System.Nullable<int> x) => 0;

Each should produce SA1125 diagnostics with fixes to int?.

SA1130 – UseLambdaSyntax

Purpose

Prefers => lambda syntax over the old delegate (...) { } anonymous method syntax.

C# 10 interaction (natural types for delegates)

With lambda natural types, delegate expressions can now appear in more places (e.g. directly assigned to var because the compiler infers a delegate type):

var f = delegate(int y) { return y + 1; };

This remains an anonymous method and should still be replaced with a lambda:

var f = (int y) => y + 1;

Required changes

Implementation

No major changes expected:
- SA1130 already registers on AnonymousMethodExpressionSyntax.
- That syntax node is present regardless of whether the anonymous method is used as a variable initializer, returned, etc.
Just ensure no context is being filtered out where anonymous methods can now appear due to natural typing.
Documentation

Rule intent remains “prefer lambdas over delegate”. Optionally note:
- C# 10 allows anonymous methods in more contexts via natural types, and all of these still fall under SA1130.
Tests

Add tests like:
```
var f = delegate() { return 42; };
object o = delegate() { };
```
Ensure SA1130 fires and the code fix converts them to () => 42 and () => { } respectively.

SA1141 – UseTupleSyntax

Purpose

Requires tuple literal syntax (T1, T2) instead of System.ValueTuple<T1, T2> or ValueTuple.Create(...).

C# 10 interaction (tuple return type on lambdas)

With explicit lambda return types, users might write:

var projector = System.ValueTuple<int, int> (int x) => (x, x * x);

SA1141 should treat this like method return type usage and suggest:

var projector = (int, int) (int x) => (x, x * x);

Similarly, lambda parameters typed as System.ValueTuple<int,int> should be flagged.

Required changes

Implementation

Enhance SA1141 to:
- Inspect explicit return types on ParenthesizedLambdaExpressionSyntax.
- Reuse existing CheckType logic that is already used for method signatures, delegates, etc.
- Ensure lambda parameter types that are ValueTuple are already covered or add explicit handling if missing.
Documentation

Optionally add an example:

Even lambda expressions should use (T1, T2) instead of ValueTuple<T1,T2> in explicit signatures.

Tests

New tests such as:

var f = System.ValueTuple<string, int> () => ("hi", 5);
var g = (System.ValueTuple<int, int> p) => p;

Expect SA1141 diagnostics and code fixes replacing types with tuple syntax.

SA1410 – RemoveDelegateParenthesisWhenPossible

Purpose

Simplifies anonymous methods with no parameters:

delegate { ... } is preferred over delegate() { ... }.

SA1410 flags delegate() when the parameter list is empty.

C# 10 interaction (natural typing)

Natural typing allows delegate with no target type to appear in more places, e.g.:

var handler = delegate() { return 2; };
return delegate() { DoWork(); };

These are still anonymous methods with empty parameter lists and should be simplified to:

var handler = delegate { return 2; };
return delegate { DoWork(); };

Required changes

Implementation

No logic changes anticipated:
- SA1410 already inspects AnonymousMethodExpressionSyntax and looks for empty parameter lists () it can remove.
- The syntax is the same regardless of whether the anonymous method is assigned to var or used elsewhere.
Just ensure the code fix behaves correctly in these new contexts (it should simply drop the ()).
Documentation

Existing description is still accurate: “remove unnecessary parentheses after delegate when there are no parameters.”
Tests

Add tests like:
```
var handler = delegate() { return 2; };
return delegate() { DoWork(); };
```
Ensure SA1410 triggers and the code fix removes the empty parentheses.

Overall Notes and Scope

The above rules are the ones identified as needing updates or at least test coverage specifically for lambda natural types in C# 10.
Other StyleCopAnalyzers rules were reviewed and found either:
- Already compatible with lambdas in their new contexts, or
- Unaffected by this particular language feature.

The focus is on:

Handling lambdas that:
- Have attributes,
- Use explicit return types (including tuples/nullable types),
- Use anonymous delegate syntax in new positions.
Extending existing analyzers and tests to these new syntax forms without changing rule intent.

Each impacted rule should get:

Implementation tweaks (where noted),
New or expanded C# 10 / C# 11 tests (e.g., in the CSharp10/CSharp11 test directories), and
Any small documentation updates needed to mention lambda signatures and natural types explicitly.

Sources

SA1008OpeningParenthesisMustBeSpacedCorrectly.cs
SA1121UseBuiltInTypeAlias.cs
SA1125UseShorthandForNullableTypes.cs
SA1130UseLambdaSyntax.cs
SA1141UseTupleSyntax.cs
SA1410.md

Review impact of lambda natural types on existing rules #3985

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions