Feature Request: Extensions Suppression/Exclusion

[huoshan12345]

Feature Request: Extensions Suppression/Exclusion

Summary

Request for a mechanism to suppress or exclude specific extension classes when importing a namespace, to prevent unwanted third-party extensions from polluting the current scope.

Problem Statement

Third-party libraries sometimes place extension methods in commonly-used namespaces like System. When developers need to import these namespaces for core types, they are forced to also import all extensions from third-party libraries, which can cause conflicts and performance issues.

Growing Urgency

Since C# 14 is introducing expanded extension capabilities (properties, operators, indexers, events), the extension pollution problem will become significantly worse.

Current Problematic Scenario

// Third-party library defines extensions in System namespace
namespace System
{
    public static class ThirdPartyExtensions
    {
        public static string MyConflictingMethod(this string input) { ... }
        public static bool SomeMethod(this Exception ex) { ... }
        // ... 50+ more extension methods
    }
}

// In my code
using System; // FORCED to import ThirdPartyExtensions too

public class MyClass
{
    public void Test()
    {
        var ex = new Exception(); // Need System namespace for Exception
        // But now ex.SomeMethod() appears in IntelliSense from third-party
        // Conflicts with my own extensions or preferred patterns
        // IntelliSense becomes slow due to extra methods
    }
}

Issues This Creates

1. Forced Import: Cannot use core types without importing unwanted extensions
2. Method Conflicts: Third-party extension names conflict with local extensions
3. IntelliSense Performance: Large numbers of extension methods slow down IDE
4. Code Clarity: Unwanted methods appear as available options
5. No Control: Developers have no way to opt-out of specific extensions

[Richiban]

Third-party libraries often place extension methods in commonly-used namespaces like System

Do you have any examples of this? It sounds absolutely terrible

[huoshan12345]

Third-party libraries often place extension methods in commonly-used namespaces like System

Do you have any examples of this? It sounds absolutely terrible

https://github.com/abpframework/abp/blob/d783138ca991a968757abfad012cafa52407a1dc/framework/src/Volo.Abp.Core/System/AbpStringExtensions.cs#L9

[jaredpar]

Third-party libraries sometimes place extension methods in commonly-used namespaces like System. When developers need to import these namespaces for core types, they are forced to also import all extensions from third-party libraries, which can cause conflicts and performance issues

I understand the problem here but at the same time, this feels like feedback for the library authors. They are the ones defining public extensions to types in System. It seems appropriate to push back on them, describe the pain, and ask the extensions move to internal or to a sub-namespace that consumers can optionally import.

Not sure having a language feature here is the appropriate recourse. If we take this then should we next take a request to ban operators that have implicit conversions to / from types in the System namespace?

[333fred]

Since C# 14 is introducing expanded extension capabilities (properties, operators, indexers, events), the extension pollution problem will become significantly worse.

In particular, I want to push back on this idea. We've had extension methods in C# for well on 15 years now. Could it become worse? Yes. Could it become significantly worse? Seems extremely unlikely.