Small feature request for C# 12: scoped using and using static statements.

[carnitron]

I have one request I'd like to throw in related to using aliases for any type. Maybe it's a separate feature, I'm not sure. I haven't and won't have time in the immediate future to put together a super tight spec, so forgive me if I have overlooked something.

Request:
I would like to be able put using statements in any scope, not just at the top of the file. And the aliases would apply to just that scope.

Reasons:

1. I want to make an alias to a nested type in a nested class, but since I have to put it at the top of the file, I have to expose it outside of the parent class, if it's even possible in the situation.
2. I often use nested static classes to fully qualify big banks of constants and similar static functions. Fully qualifying them ensures clarity and prevents naming collisions. But it is a lot to type. I know this is why you added "using static" syntax. But all of those usings are up at the top of the file. So you lose the clarity they bring at the point of usage. If you could put them NEXT to the point of usage, you'd get the best of both worlds: minimal typing AND clarity.
3. When I use the "using static" syntax to minimize what I have to type, it's easy to get into situations where can't tell what constant/function/etc. is backed by an alias and where it came from. Since the fully qualified name is gone, the syntax often makes it look like the thing I am referring to is local to the class and not from somewhere else.
4. Sometimes naming collisions in like namespaces prevent you from being able to remove all of your naming qualifications.

Example:

So this:

public void Thing(double[] numbers)
{
    double average = A.B.C.D.E.F.Metric.Average(numbers);
    double stdDev = A.B.C.D.E.F.Metric.StandardDeviation(numbers);
    // ... Many more metrics.
}

Or this:

// Way at the top of the file.
using static A.B.C.D.E.F.Metric;

// Pages of code later:
public void Thing(double[] numbers)
{
    double average = Average(numbers);
    double stdDev = StandardDeviation(numbers);
}

Would become this:

public void Thing(double[] numbers)
{
    using static A.B.C.D.E.F;

    double average = Metric.Average(numbers);
    double stdDev = Metric.StandardDeviation(numbers);
}

Or even better, this:

public void Thing(double[] numbers)
{
    // Adding the "connecting" definition here makes it completely unambiguous what functions I'm using at the call site.
    using static Metric = A.B.C.D.E.F.Metric;

    double average = Metric.Average(numbers);
    double stdDev = Metric.StandardDeviation(numbers);
}

Hope this all makes sense. Thx for reading.

[ufcpp]

Similar to #2981 (but class scope instead of method scope)

[carnitron]

What happens if there is no feedback on an issue? Is it added to a list somewhere? Or is this taken as an indicator there is insufficient interest in the idea?

[CyrusNajmabadi]

Or is this taken as an indicator there is insufficient interest in the idea?

It's a signal. But one of many we care about.

Is it added to a list somewhere?

The "discussions" are the list of things we're interested in.

[carnitron]

Ok, makes sense. Thanks for clarifying.

[Jiiks]

In your example I assume you meant:

public void Thing(double[] numbers) {
    // Adding the "connecting" definition here makes it completely unambiguous what functions I'm using at the call site.
    using static Metric = A.B.C.D.E.F.Metric;

    double average = Average(numbers);
    double stdDev = StandardDeviation(numbers);
}

Would personally love this feature. Even blocks something like:

public void Thing(double[] numbers) {
    // Adding the "connecting" definition here makes it completely unambiguous what functions I'm using at the call site.
    using(static A.B.C.D.E.F.Metric) {
        double average = Average(numbers);
        double stdDev = StandardDeviation(numbers);
    }
}

[carnitron]

I let the client site include the "Metric" in front of Average, just for clarity, b/c when there are multiple packages in play, sometimes I like to be able to make it extra clear which version of a function I am using with a preface token. But either way is good -- the main point is that we see the package that is in play in the code block. The using syntax is interesting too, b/c that is also super clear.

[martin-steinhoefer]

I could imagine, that this feature can eliminate the need of disambiguation of extensions completely (i.e. we need a disambiguation syntax just for compatibility with 'legacy' extension methods). For that, aliases would not be required.