Feature Request: Exclude class from namespace 'using' directive

[exts]

There are times when you want to use a collection of classes, but there may be a chance that a class in that directive you don't want to use is included and conflicts with an existing included namespace. There should be some sort of syntatic sugar that allows c# to be smart enough to say "no don't include this at all" to avoid these problems.

Something as simple like:

using DirectiveName except Foo;

or

using DirectiveName except (Foo, Bar); and if we have 3 classes 'Foo, Bar and Buzz' in that directive only Buzz gets included.

[svick]

What makes this:

using NamespaceOne except Foo;
using NamespaceTwo;

better than what you can already do:

using NamespaceOne;
using NamespaceTwo;
using Foo = NamespaceTwo.Foo;

?

[exts]

@svick well for starters in my example 'Foo' is a class within NamespaceOne and NamespaceTwo and not another namespace. Now when you start running into re-implementation's of generic classes like Dictionary it would be easier to just exclude Dictionary from a using statement when you still want to use other classes from that namespace rather than trying to define every type of generic method as an alias from that directive.

Things also get weird when you need a majority of classes from an api are in the same namespace. It just seems unnecessary to include every single class you're using from one or the other namespace just to avoid an ambitious reference error.

tl;dr it gets messy depending on the type. You also shouldn't be forced to change all your code when introducing a new library to your project because it's easier to just exclude the conflicting class than to deal with ambiguous reference errors by using fully qualified names when later you could easily remove that library and now you've already updated your code to deal with this issue. It's unnecessary.

I'm sure other people have some examples, but it just seems like a nice QoL change that wouldn't break backwards compatibility.

[svick]

@exts

in my example 'Foo' is a class within NamespaceOne and NamespaceTwo and not another namespace.

It's like that in my example too.

It just seems unnecessary to include every single class you're using from one or the other namespace just to avoid an ambitious reference error.

You don't need to do that, what you need is a using alias directive (like the one in my example) for the ambiguous types. You don't need to include classes that are not ambiguous one by one.

You also shouldn't be forced to change all your code when introducing a new library to your project because it's easier to just exclude the conflicting class than to deal with ambiguous reference errors by using fully qualified names […]

You don't have to. If you know which class is ambiguous, you can use a using alias directive for that one class and you're done.

[exts]

@svick so if I'm using multiple Dictionary<TKey, TVal>'s your solution is to create an alias for every conflicting one and be done? That's so unnecessary.

[svick]

@exts Sorry, it wasn't clear to me that you're dealing with generics.

In that case, my solution is to improve the using alias directive to support generics: #1239, instead of introducing a completely new concept to the language.