Proposal: Add support for class level using statements

[gafter]

@TyreeJackson commented on Tue Aug 11 2015

Problem

When using nested classes, especially combined with generic type parameters, resolving nested types outside of their nesting hierarchies and from within another set of nested class hierarchies become clunky and difficult to read.

Consider the following example classes. (Note, that in the real world version of this example, the nested classes would be in separate files and partial class signatures would be used to span the nesting classes across the files. The main class file for any class would solely contain the full class signature.)

public class A<TA> where TA : A<TA>
{
    public  class   B<TB, TC, TD, TE, TF>
            where   TB : B<TB, TC, TD, TE, TF>
            where   TC : B<TB, TC, TD, TE, TF>.BaseC
            where   TD : B<TB, TC, TD, TE, TF>.BaseD
            where   TE : B<TB, TC, TD, TE, TF>.IBaseE
    {
        public  class       BaseC   {}

        public  class       BaseD   {}

        public  interface   IBaseE  {}

        public  class       G<TG, TH> : IBaseE
                where       TG : G<TG, TH>
                where       TH : G<TG, TH>.IBaseH
        {
            public  interface   IBaseH {}

            public  class       I<TI, TJ> : IBaseH
                    where       TI : I<TI, TJ>
                    where       TJ : I<TI, TJ>.BaseJ
            {
                public  delegate    IEnumerable<TC> FilterQ(IQueryable<TJ> tj, TC tc);

                public  class       BaseJ   {}

                public  interface   IBaseK  {}

                public  class       BaseK : IBaseK   {}
            }
        }
    }
}

Now consider the following unit test classes. (Note, that again in the real world that these classes would be separated into multiple files using partial class declarations.)

[TestClass]
public class A_tests<TA> where TA : A<TA>
{
    [TestClass]
    public  class   B_tests<TB, TC, TD, TE, TF>
            where   TB : A<TA>.B<TB, TC, TD, TE, TF>
            where   TC : A<TA>.B<TB, TC, TD, TE, TF>.BaseC
            where   TD : A<TA>.B<TB, TC, TD, TE, TF>.BaseD
            where   TE : A<TA>.B<TB, TC, TD, TE, TF>.IBaseE
    {
        [TestClass]
        public  class   G_tests<TG, TH>
                where   TG : A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>
                where   TH : A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>.IBaseH
        {
            [TestClass]
            public  class   I_tests<TI, TJ, TK>
                    where   TI  : A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>.I<TI, TJ>
                    where   TJ  : A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>.I<TI, TJ>.BaseJ
                    where   TK  : A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>.I<TI, TJ>.IBaseK
            {
                protected Mock<TK> mockK;

                protected TH createIH(Func<TK> createTK, A<TA>.B<TB, TC, TD, TE, TF>.G<TG, TH>.I<TI, TJ>.FilterQ filterQ) { return default(TH); }
            }
        }
    }
}

Notice how clunky and unwieldy the source class type names are getting in the test classes at their corresponding levels in the hierarchy.

Proposal

Add support for the using statement within the scope of a class in a specific file.

It would be great if we could write the following for the test classes in place of the above:

[TestClass]
public class A_tests<TA> where TA : A<TA>
{
    using A : A<TA>;

    [TestClass]
    public  class   B_tests<TB, TC, TD, TE, TF>
            where   TB : A.B<TB, TC, TD, TE, TF>
            where   TC : A.B<TB, TC, TD, TE, TF>.BaseC
            where   TD : A.B<TB, TC, TD, TE, TF>.BaseD
            where   TE : A.B<TB, TC, TD, TE, TF>.IBaseE
    {
        using B : A.B<TB, TC, TD, TE, TF>;

        [TestClass]
        public  class   G_tests<TG, TH>
                where   TG : B.G<TG, TH>
                where   TH : B.G<TG, TH>.IBaseH
        {
            using G : B.G<TG, TH>;

            [TestClass]
            public  class   I_tests<TI, TJ, TK>
                    where   TI  : G.I<TI, TJ>
                    where   TJ  : G.I<TI, TJ>.BaseJ
                    where   TK  : G.I<TI, TJ>.IBaseK
            {
                using I : G.I<TI, TJ>;

                protected Mock<TK> mockK;

                protected TH createIH(Func<TK> createTK, I.FilterQ filterQ) { return default(TH); }
            }
        }
    }
}

Class level using statements would greatly help in cases where generic type parameters are being shared across multiple nested classes in multiple levels of class nesting.

I apologize for the obfuscation of the type names in the example above.

---

@dsaf commented on Tue Aug 11 2015

Looks like a very narrow use case on the surface.

I apologize for the obfuscation of the type names in the example above..

Not sure if naming is the biggest problem with readability here. It is very tempting to provide critique of the example code instead of the suggested language feature:

...in the real world that these classes would be separated into multiple files using partial class declarations...
... cases where generic type parameters are being shared across multiple nested classes in multiple levels of class nesting...

---

@TyreeJackson commented on Tue Aug 11 2015

@dsaf
Please critique away. I'm always up for learning a new way to solve a problem.

If you are concerned with the use of partial classes and sharing of generic type parameters across nested classes, I will state that I've tried numerous approaches to enforce type safety across these 'layers' for years. In order to reduce redundant type parameter declarations and type casting, the best solution I came up with was to share type parameters across multiple types by nesting them within an outer class that declares the type parameters. In fact, I just submitted a different "issue" on here to discuss that very concept and the idea of introducing generic/parametric modules or namespaces. Check it out on #4494. The same code from this issue is used there to demonstrate the problem of breaking out the classes directly into classical namespaces.

---

@svick commented on Sat Apr 02 2016

Note that this is not about the using statement, it's about the using directive. @TyreeJackson could you change the title of the issue?

[GSPP]

I was about to raise a similar issue: using inside of a method or even a block ({}). That would be useful for static helper functions e.g.

void PrintUsage() {
 using System.Console;

 WriteLine("myprogram.exe arg1 arg2");
 WriteLine("...");
 WriteLine("...");
}

You might not want to pull in global functions into the entire file.

I thought this was a good feature suggestion because it appears to not cause a lot of work compared to the benefit.

I now see that this was raised before in a similar way: Proposal: using directives everywhere #218.