[Proposal] Using directives at class level

[Orace]

Actually using directives are declared at the head of a namespace or before any namespace.

This proposal is about adding using directive at class level.
Especially using alias and using static directives:

// using alias example
class FooBarMapper
    using FooByBar = System.Collections.Generic.Dictionary<Bar, Foo>
{
    private readonly FooByBar _fooByBar;

    public FooBarMapper(FooByBar fooByBar)
    {
        _fooByBar = fooByBar;
    }

    public Foo GetFor(Bar bar) => _fooByBar[bar];
}

// using alias example with type parameters
class Mapper<TBar, TFoo>
    using FooByBar = System.Collections.Generic.Dictionary<TBar, TFoo>
{
    private readonly FooByBar _fooByBar;

    public Mapper(FooByBar fooByBar)
    {
        _fooByBar = fooByBar;
    }

    public TFoo GetFor(TBar bar) => _fooByBar[bar];
}

// This allow a same alias name to have different meaning in a same file
class Foo
  using Logger = FooLoggerNamespace
{
...
}

class Bar
  using Logger = BarLoggerNamespace
{
...
}

// using static example
class Program
    using static System.Console
{
    static void Main(string[] args)
    {
        WriteLine("Hello");
    }
}

class CalculHelper
    using static System.Math
{
// some code using a lot of System.Math
}

This is a prelude to #2936

[DaZombieKiller]

Nitpick, but the semicolon makes the syntax inconsistent with all other class-level syntax elements (such as where clauses). Also, what about struct, enum, interface, delegate and namespace?

[Orace]

@DaZombieKiller, I removed the semicolons, thanks.
I think this is portable to struct, enum, interface and delegate (anywhere you can put a where).
But since it does not apply backward it's useless for delegate.
For alias declaration at the class (struct, enum or interface) level see the as proposition I made here: #2936

[theunrepentantgeek]

// This allow a same alias name to have different meaning in a same file

😕 Why is this a good idea?

As far as I can see, the only result of this would be to make it significantly harder to reason about the source in that file, it would be a fertile source of hard to understand bugs.

For example, relocating a method from a sub-class to a parent-class might completely change the nature of the method in an incompatible way.

Worst of all, this isn't pay-to-play because the mere presence of this feature in the language would require everyone to pay a price, regardless of whether it was used or not.

[Orace]

// This allow a same alias name to have different meaning in a same file

Why is this a good idea?

I never say it was, it's an effect of the proposal.

For example, relocating a method from a sub-class to a parent-class might completely change the nature of the method in an incompatible way.

Indeed like using aliases actually do when you relocate some code from one file to an other and the using aliases are not the same in the two files.

Worst of all, this isn't pay-to-play because the mere presence of this feature in the language would require everyone to pay a price, regardless of whether it was used or not.

Sorry, I don't get your point, could you expand on that ?
Turning on this feature doesn't impact existing code.
The effect of the feature is restrained to the (partial) class where it's activated.

[atifaziz]

@Orace 👋🏼 I would challenge that why aren't you asking for this at lower levels than the class? Why not even go all the way down to the method-level?

[theunrepentantgeek]

@Orace asked

Sorry, I don't get your point, could you expand on that ?

If an existing C# project uses aliases (the vast majority of those that I've seen do not), they'll be found at the top of the file, with effect for the entire file.

Moving a piece of code from one place to another within that file (say, by promoting a method into a parent class, or by demoting it into a subclass) won't change the definition of any of the types used by that method.

If every class is potentially defining it's own type aliases, perhaps even with the same name, simple refactoring becomes much more dangerous because the type Foo I read in one piece of code isn't the same Foo that I read in another piece of code, even in the same file.

It destroys my ability to reason about the code I'm reading.

Currently, type aliases in C# are rarely used - it's a feature useful for disambiguation of conflicting simple type names, and mostly it's not needed. This is a good thing.

C# doesn't need additional features that encourage obfuscation of code for the benefit of saving a few moments of typing. Code is read far more often than it's written.