[Proposal] Generic Type Parameters for Namespaces.

[armstrom]

This proposed feature allows for a handy design pattern where a library can provide generic implementations of types that should always be used together with the matching type parameters. This idea flows from my use of the numerical interfaces introduced in .NET 7 hence my example code... This feature is mostly "syntax sugar" as it doesn't provide any capability that you can't achieve with the language today, it just makes the code cleaner and communicates intent better.

NOTE: This is really not useful for single stand-alone Generic types that we are used to using. Things like List<T> or Span<T>. In these cases there is no value in specifying a shared generic type parameter since these types are often used in isolation and a single method may use several concrete types with different type parameters (List<int>() List<SomeClass>(), etc... ) Rather, this feature is for groups of types that regularly interoperate with each other and need to keep consistent generic type parameters between them. In addition, it only makes sense if a particular file ALWAYS uses the same type parameter when using these types so you end up specifying the same parameter over and over again.

Here's an example of how it would work. Assume we're dealing with a basic 3D math library and I want to support both single and double precision floating point values for all of my types.

Today I can do this:

namespace Math3D
{
    public struct Point3D<T>(T x, T y, T z) where T : IFloatingPoint<T>
    {
        public T X { get; set; } = x;
        public T Y { get; set; } = y;
        public T Z { get; set; } = z;

        public static Point3D<T> operator +(Point3D<T> p, Vector3D<T> v) => new Point3D<T>(p.X + v.I, p.Y + v.J, p.Z + v.K);
        public static Vector3D<T> operator -(Point3D<T> p1, Point3D<T> p2) => new Vector3D<T>(p1.X - p2.X, p1.Y - p2.Y, p1.Z - p2.Z);
    }

    public struct Vector3D<T>(T i, T j, T k) where T : IFloatingPoint<T>
    {
        public T I { get; set; } = i;
        public T J { get; set; } = j;
        public T K { get; set; } = k;
    }

    public struct Matrix4<T> where T : IFloatingPoint<T>
    {
        public Point3D<T> Transform(Point3D<T> point)
        {
            //You get the idea... 
            return new Point3D<T>(point.X, point.Y, point.Z);
        }
    }
}

Usage (notice how I have to keep specifying double everywhere):

using Math3D;

//create a point, specifying double precision
var point1 = new Point3D<double>(1, 2, 3); 

 //create a double precision transformation
var coordSys= new Matrix4<double>();
var point1Trans = coordSys.Transform(point1);

This is what I propose as an alternative:

namespace Math3D<T> where T : IFloatingPoint<T>
{
    public struct Point3D(T x, T y, T z)
    {
        public T X { get; set; } = x;
        public T Y { get; set; } = y;
        public T Z { get; set; } = z;

        public static Point3D operator +(Point3D<T> p, Vector3D v) => new Point3D(p.X + v.I, p.Y + v.J, p.Z + v.K);
        public static Vector3D operator -(Point3D<T> p1, Point3D p2) => new Vector3D(p1.X - p2.X, p1.Y - p2.Y, p1.Z - p2.Z);
    }

    public struct Vector3D(T i, T j, T k)
    {
        public T I { get; set; } = i;
        public T J { get; set; } = j;
        public T K { get; set; } = k;
    }

    public struct Matrix4
    {
        public Point3D Transform(Point3D point)
        {
            //You get the idea... 
            return new Point3D(point.X, point.Y, point.Z);
        }
    }
}

Now the generic type parameter T is specified once at the namespace definition (along with the constraint). I can then use T anywhere within the types contained in the namespace and it will be resolved to the same type.

New Usage:

using Math3D<double>;  //All our Math3D types will be double precision within the scope of this using statement. No need to specify!

//create a point
var point1 = new Point3D(1, 2, 3); 

 //create a transformation
var coordSys= new Matrix4();
var point1Trans = coordSys.Transform(point1);

The main drawback/hurdle I see is if for some reason someone wants to use the same namespace with two different parameters within the same file (mixing single and double precision 3D Math?). In these cases it should be possible to create an alias for the namespace with the generic parameters resolved like this:

using Single3D = Math3D<float>;
using Math3D<double>;

var singlePrecisionPoint = new Single3D.Point3D(...);
var doublePrecisionPoint = new Point3D(...);

[HaloFour]

You could do this with nested classes.

static class Math3D<T> where T : IFloatingPoint<T>
{
    public struct Point3D(T x, T y, T z)
    {
        public T X { get; set; } = x;
        public T Y { get; set; } = y;
        public T Z { get; set; } = z;

        public static Point3D operator +(Point3D<T> p, Vector3D v) => new Point3D(p.X + v.I, p.Y + v.J, p.Z + v.K);
        public static Vector3D operator -(Point3D<T> p1, Point3D p2) => new Vector3D(p1.X - p2.X, p1.Y - p2.Y, p1.Z - p2.Z);
    }

    public struct Vector3D(T i, T j, T k)
    {
        public T I { get; set; } = i;
        public T J { get; set; } = j;
        public T K { get; set; } = k;
    }

    public struct Matrix4
    {
        public Point3D Transform(Point3D point)
        {
            //You get the idea... 
            return new Point3D(point.X, point.Y, point.Z);
        }
    }
}

Namespaces don't really exist as far as the runtime is concerned. They are part of the type name themselves.

[armstrom]

The types are the only things being made generic.. the namespace itself isn't actually generic... as you said in your previous comment, as far as the runtime is concerned namespaces aren't a thing. C# is riddled with syntax that, for the sake of convenience or brevity, makes code that "looks" like something other than what it is.
Primary constructors... classes can't take parameters (other than generic type parameters) so why on earth would we make a syntax that looks like they do? How about auto properties? lambdas and delegates? Why am I pretending I can invoke a variable as if it were a method?

I'm not sure I follow on why arity would be changed "silently".. You would have to specify the type parameters in the namespace every time... so it wouldn't be ambiguous or defined magically in some other file. Also, it doesn't make the generic type look non-generic any more than any other type aliaising through the using keyword already does... The using statement simply creates aliases for you and you would still be free to access the types without the special syntax and they would clearly be generic types.
When you see this code: var myTimer = new Timer(); are you just as confused? am I talking about System.Threading.Timer, System.Timers.Timer, System.Net.TimerThread, System.Windows.Forms.Timer?? How do you know? You check the using statement in your file, or you over on the type and intellisense tells you what you're dealing with.

[HaloFour]

I'm not sure I follow on why arity would be changed "silently"

You are declaring the class as non-generic, but it is generic.

If you want a syntax feature to generate aliases, why not just use aliases? They can be globally defined.

[GalaxiaGuy]

You are declaring the class as non-generic, but it is generic.

Isn't this also true of nested classes though? The inner class looks non-generic.

[HaloFour]

Isn't this also true of nested classes though? The inner class looks non-generic.

Nested types are a part of their enclosing type, so the full name of the type does include the generic parameter. Importantly, this already works.

[CyrusNajmabadi]

I think that instead of using namespaces for this, we'd likely go a "module" route. Where modules themselves could be generic.

[armstrom]

I'm not sure I follow on why arity would be changed "silently"

You are declaring the class as non-generic, but it is generic.

I'm sorry, but that's simply not true. The syntax declares it as generic implicitly by A) being defined within the scope of a namespace that has been decorated with generic type parameters and B) making use of one or more of those type parameters within the class somewhere. While it's not explicit definition as you would see today it is definitely not magic out of nowhere... the author has to do something visible within the code to cause the behavior. This is what evolving language syntax looks like... it's a new way to do something different than how you might do it today.

If you want a syntax feature to generate aliases, why not just use aliases? They can be globally defined.

Again... we're talking about evolving syntax of a language. Most of your concerns have fallen under the general category of "but that's not how C# does that... why not just do it the long and verbose way that is already supported?" By that logic why should we even have auto properties, record types, extension methods, lambda expressions, primary constructors, initializers? ALL of these things were possible with the language in some way before they existed. NONE of these features added any functionality beyond quality of life...Why have any of them been added to the language? I understand you may not like the proposal, that's fine. And I do appreciate the discussion, it's made me think about what I'm proposing and other shortcomings it may have... I will say, however, that this proposed syntax would be just as optional as any other syntax sugar that has been added to the language over the 20+ years I've been using it. Don't like var? don't use it! Want to manually specify backing fields for all of your properties? knock yourself out! Think extension method "lie" about what methods are available in a given type? Don't use them....

[HaloFour]

The syntax declares it as generic implicitly

That is the problem.

Again... we're talking about evolving syntax of a language. Most of your concerns have fallen under the general category of "but that's not how C# does that..

None of those features affect the surface APIs. They are implementation details. The team has been pretty clear that they prefer that anything that impacts the API be an explicit part of the code.

I empathize with wanting to make the use of generic containers in such code easier, but I don't think having the language pretend that namespaces can be generic types is a way to accomplish this.

That's just my opinion, though.

[theunrepentantgeek]

Don't like var? don't use it!
Want to manually specify backing fields for all of your properties? knock yourself out!
Think extension method "lie" about what methods are available in a given type? Don't use them....

This argument is routinely brought out as a way to try and shut down discussion - and it's, frankly, completely specious.

"I don't like it, so I won't use it" is only valid for projects that will only ever be maintained by a single developer.

The overwhelming majority of C# projects will be maintained by multiple developers - due simply to the passage of time, the size of the project, or simply because someone in the business recognizes there's too much risk in having everything dependent on one person who might have an unexpected encounter with a wayward bus or a lucky lotto ticket.