New rules for tuple types

Normally I would propose the new rules individually, but in this case I believe the individual rules are closely related and likely need to be implemented as a group.

📝 All of the following rules are automatically disabled if the project does not support C# 7 or newer.

SA1141: Use tuple syntax

Category: Readability

This rule catches three cases:

1. Prefer (T1, T2) to ValueTuple<T1, T2>
2. Prefer (value1, value2) to ValueTuple.Create(value1, value2)
3. Prefer (value1, value2) to new ValueTuple<T1, T2>(value1, value2)

📝 As an aside, it appears the new tuple type syntax is not allowed inside pattern matching so it needs to be tested.

SA1414: Tuple types in signatures should have element names

Category: Maintainability

Tuple types appearing in element signatures should have explicitly named tuple elements.

SA1142: Refer to tuple elements by name

Category: Readability

This rule reports diagnostics when a tuple field is referenced by its metadata name (Item1, etc.) when a name has been provided.

SA1316: Tuple element names should start with a lowercase uppercase lowercase letter

Category: Naming

Tuple element names should be in camelCase PascalCase camelCase.

This rule will have a configuration option to analyze implicit names (C# 7.1). In the default configuration, only explicitly-provided names would be analyzed.

SA1317: Tuple element names in signatures should match

Category: Naming

See dotnet/roslyn#20850 See #1949

[appel1]

@sharwell I hope you can still make this configurable. For us it makes sense to keep the naming convention the same for all public fields and properties. Very odd to make an exception for just named value tuple fields, the ItemN fields are still pascal cased even.

[sharwell]

Based on the updated conclusion in dotnet/corefx, I’ve updated the rules above to again suggest camelCase naming. This is consistent will all cases of tuple usage I’ve observed to date.