[API Proposal]: extend 'Attribute' model for feature APIs for custom feature switches

[Sergio0694]

Background and motivation

This proposal is a follow up to #96859, with the goal being to implement the ability to get analyzer support for custom feature switches. This was initially discussed there as well, but was then removed from the initial proposal. We have several scenarios where this would be great to have:

• CsWinRT: we have several feature switches available, and right now there is no way to easily understand how they affect the code execution at runtime. This makes it less intuitive for customers to use them, and it also makes it more difficult for us to maintain the codebase, as we have to "just know" what code paths will fail or not depending on combinations of feature switches.
• Windows feature flags: as we're continuing to adopt C# for OS components, we also implemented a C# backend to check feature flags at runtime. This is extremely widespread in all C# components in Windows, but right now it has no analyzer support whatsoever, making things more brittle and more difficult to maintain. This is another scenario where we could really use support for custom feature flags.
• MVVM Toolkit: we have a number of feature switches here too, but no way to provide customers with analyzer support so they can easily validate that they're not trying to use code that won't work if they disabled a given feature switch.

The proposal is to make it possible for developers to leverage the same analyzer as for trimming/AOT, but for custom feature switches too.

Prior design discussion: dotnet/designs#305.

API Proposal

  namespace System.Diagnostics.CodeAnalysis;
  
- [AttributeUsage(AttributeTargets.Property, Inherited = false)]
+ [AttributeUsage(AttributeTargets.Property | AttributeTargets.Class, Inherited = false)]
  public sealed class FeatureSwitchDefinitionAttribute : Attribute
  {
      public FeatureSwitchDefinitionAttribute(string switchName);
  
      public string SwitchName { get; }
  }

The role of [FeatureCheck] is to allow 3rd party libraries to define a relationship between a property representing a feature switch, and an attribute they can define to annotate members that rely on that custom feature switch, such that the analyzer can correctly warn (or not) upon usage.

API Usage

The goal is to make this scenario work as follows:

[FeatureSwitchDefinition("MyCustomFeature")]
public static bool IsMyCustomFeatureSupported { get; } = AppContext.TryGetSwitch("MyCustomFeature", out bool flag) ? flag : true;

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Constructor | AttributeTargets.Class, Inherited = false)]
[FeatureSwitchDefinition("MyCustomFeature")]
public sealed class RequiresMyCustomFeatureAttribute : Attribute;

class Program
{
    public void Test()
    {
        M(); // Warns
    
        if (IsMyCustomFeatureSupported)
        {
            M(); // Does not warn
        }
    }
    
    [RequiresMyCustomFeature]
    private void M()
    {
    }
}

Risks

No risk. The current situation is strictly worse, as there's no way for 3rd party authors to easily validate feature switch dependent scenarios.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[julealgon]

Why introduce an indirection to a secondary attribute?

Wouldn't this work and be significantly simpler?

[RequiresFeature("MyCustomFeature")]
private void M()
{
}

Additionally, wouldn't it always make sense to check AppContext for the feature switch, instead of leaving it open using an arbitrary bool function?

And lastly, won't this create a semantic conflict with Microsoft.FeatureManagement? Are you fine with the confusion that this will bring into the ecosystem? Was there any consideration about "unifying" these 2 concepts before introducing extra abstractions?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/illink
See info in area-owners.md if you want to be subscribed.