Proposal: File scoped namespaces

[bomzj]

Spec: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/file-scoped-namespaces.md

How it looks now:

using System;

namespace Company.Project
{
    public class Product
    {        
        ...
    }
}

Why do we need to nest our class definition in namespace ? Why not to remove extra nesting ?
Isn't that better ?

namespace Company.Project
using System;

public class Product
{ 
    ...
}

LDM history:

• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-02-10.md#namespace-directives-in-top-level-programs
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-01-13.md#file-scoped-namespaces
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-01-05.md#file-scoped-namespaces

[scottdorman]

Well, one reason is that namespaces can be nested. thereby creating additional scopes. For example, your code

using System;

namespace Company.Project
{
    public class Product
    {        
        ...
    }
}

could also be written as

using System;

namespace Company
{
    namespace Project
    {
        public class Product
        {
        }
    }
}

In both cases the full type name, including the namespace, becomes Company.Project.Product.

Also, using directives can be either outside the namespace, as in your example, or inside the namespace, which changes the scoping of that using directive.

[bondsbw]

Assuming the proposal does not remove the ability to nest namespaces (which would break all existing C# code), this could improve indentation for the vast majority of code.

#114 has similar goals.

[scottdorman]

@bondsbw So you're saying that if this proposal were implemented we'd have 3 different ways to write the same scoped namespace?

using System;

namespace Company.Project
{
    public class Product
    {        
        ...
    }
}

or

using System;

namespace Company
{
    namespace Project
    {
        public class Product
        {
        }
    }
}

or

namespace Company.Project
using System;

public class Product
{ 
    ...
}

Would this new variation of the namespace directive support nesting, and if so, how? Would this be an implicit scope such that when I encounter the next namespace directive in the file it creates a nested namespace? That wouldn't work because I can have multiple top-level namespaces in a single file (never mind the question of whether or not that's a good idea, it's possible today and I've seen code that uses that ability, which would then break).

For example, if I wrote

namespace Company
using System;

namespace Project
public class Product
{ 
    ...
}

Does this compile Product to be Company.Project.Product or Project.Product?

I also noticed that the using directive is in a different spot in the original examples. In the first (what we have today in C#) it's outside the namespace. In the proposed code, it would be scoped to be inside the namespace (based on it's placement after the namespace directive). So, the original proposed code

namespace Company.Project
using System;

public class Product
{ 
    ...
}

would be equivalent to

namespace Company.Project
{
   using System;

   public class Product
   {  
       ...
   }
}

[bomzj]

Weird idea of using multiple namespaces in one file which should define one entity (class). I don't remember any sample where I need to have several namespaces in one file or nesting them which produces mass of indentation as result hard to read such code.

[scottdorman]

@bomzj I never said that multiple top-level namespaces in one file was a good idea, only that we can do it now and I've seen code files that take advantage of that. Having multiple nested namespaces in one file is also something we can do now and has completely unambiguous nesting semantics.

[bondsbw]

@bondsbw So you're saying that if this proposal were implemented we'd have 3 different ways to write the same scoped namespace?

Yes. Proposals to break backward compatibility are DOA except in the most minor cases. It would be a huge break to remove the block syntax.

[bbarry]

My vote would be: allow a file to allow up to 1 file level namespace directive per file and that it must come before any container namespace directives or type declarations.

Differentiate between a "file level namespace directive" and a "container namespace directive" by the fact that a file level one would not have a body and must have a semi:

namespace_declaration
    : file_namespace_declaration
    | container_namespace_declaration
    ;

file_namespace_declaration
    : 'namespace' qualified_identifier ';'
    ;

container_namespace_declaration
    : 'namespace' qualified_identifier namespace_body ';'?
    ;

Such a namespace directive would act as if it was a container namespace containing the rest of the file.

[scottdorman]

@bondsbw Yes, proposals which break back compatibly are DOA. I still don't see how this change provides any major benefit other than not having a level of indenting, which is fairly inconsequential.

@bbarry So you're saying that we would have a new namespace <identifier>; directive that would have to be at the top of the file? So, in the example we've been using here, namespace Company.Product; would have to be the first line and I can only have one of them? This would prevent me from defining more than one top-level namespace per file and also prevent me from having using directives appear outside the namespace declaration.

[bbarry]

No you could have using directives both above and below a file namespace directive. But you cannot have multiple file namespace directives and if you have 1, you cannot have container namespace directives or type declarations before the file namespace directive. using directives before the file namespace directive would be treated as outside and ones after, inside.

in examples:

ex1: (valid C# today)

using System;
namespace Company.Project
{
    using System.Collections;
    public class Product { }
}

or

ex2: (valid C# today)

using System;
namespace Company
{
    using System.Collections;
    namespace Project
    {
        public class Product { }
    }
}

or

ex3: (proposed, equal semantics to ex1)

using System;
namespace Company.Project;
using System.Collections;
public class Product { }

or

ex3: (proposed, equal semantics to ex2)

using System;
namespace Company;
using System.Collections;
namespace Project
{
    public class Product { }
}

but not:

ex5 (admittedly an arbitrary example, but the rational would be that if you are using both a container namespace and a file namespace it is because you have more than one container in your file or you require the semantics of ex2):

using System;
namespace Company;
namespace Project;
using System.Collections;
public class Product { }

and not:

ex6 (again arbitrary; here I am explicitly denying this as in scope in this proposal to consider it potentially for the future):

using System;
namespace Company 
{
    namespace Project;
    using System.Collections;
    public class Product { }
}

and not:

ex7 (avoiding a pit of failure due to overly complex files):

using System;
namespace Whatever {};
namespace Company.Project;
using System.Collections;
public class Product { }

and not:

ex8 (again avoiding complexity):

using System;
delegate void MyFunc(string s); //or any other type decl
namespace Company.Project;
using System.Collections;
public class Product { }

[jnm2]

I was hoping this would make it over from /roslyn.

Putting the namespace in the class name appeals to me the most since I have never, ever defined more than one namespace per file. It would be great if that worked for partial classes too:

// File MyClass.cs
partial class MyNamespace.MyClass { }

// File MyClass.NestedType.cs
class MyNamespace.MyClass.NestedType { }

However, the namespace with an implied scope extending to the end of the parent scope would be an acceptable compromise. There is no possible ambiguity.

@scottdorman About ambiguity: just like the using proposal, the scope is not ambiguous. It always extends to the very end of the parent scope, the same behavior that the scope of a declared variable would have in that position. I don't care for the using syntax, but the same principle applied to namespace would be a huge benefit because four nines of the time people have a single namespace per file.

[scottdorman]

I agree, the vast majority of the time we only have one namespace per file and only have one class per file. However, that's not always the case and it's certainly not enforced by the compiler and/or IDE. (I've worked in languages that enforced this, and it got to be a real pain. That's not to say there may be good ways to actually do this where it doesn't get in your way more often than not, though.)

The ambiguity about what the scope actually is comes about if multiple namespace x; directives are allowed in a single file. Does the outermost directive define a scope such that the next directive is nested? If so, that is more limiting than what we have now where I can define the scopes however I want/need.

I'm not a big fan of having the namespace be part of the class name at all. First, it requires changing what constitutes a valid class identifier, but more importantly I think it introduces a lot of redundancy as far as namespaces go. Would the using directives just appear before the class declaration? How would you scope them to be contained within the namespace?

Given @bbarry's earlier examples, I still find this

using System;
namespace Company
{
    using System.Collections;
    namespace Project
    {
        public class Product { }
    }
}

to be considerably more readable than

using System;
namespace Company;
using System.Collections;
namespace Project
{
    public class Product { }
}

Especially since, at least to me, all this is really doing is letting me skip two curly braces and some indenting, I don't see the benefits. (I have the same issue, among others, with the implicitly scoped using statements as well.) I'd much rather see language features that make the language easier to read (which this doesn't, in my opinion) and reduce my ability to write code that can have unexpected/unintended side-effects than ones that make it harder to read and introduce more places for ambiguity.

[jnm2]

The ambiguity about what the scope actually is comes about if multiple namespace x; directives are allowed in a single file.

I don't see an ambiguity. Same with the using thing:

using (a);
// Invisible { for a

// Still using a even though no indent

using (b);
// Invisible { for b

// Still using a and b even though no indent

// Invisible } for b
// Invisible } for a

namespace a;
// Invisible { for a

// Namespace here is "a" even though no indent

namespace b;
// Invisible { for b

// Namespace here is "a.b" even though no indent

// Invisible } for b
// Invisible } for a

I agree with you that this would not be as flexible for multi-namespace files, but

1. the same goes for the using and there is an easy workaround if you need to be more specific about scope: go back to using { and } for that file
2. We're honestly talking 0.01% of the time. Let's optimize for the common scenarios that affect everyone every day. The same goes for multiple levels of using nesting. If it's too complex, choose not to do it and use { and } instead. But don't punish the almost universal case of single using block, single namespace.

[bomzj]

Why not to use 2 types of declaring namespace ? The old approach with nesting where multiple namespaces are need and new one as single line for vast majority.
One more loud thought whether it's possible to eliminate namespace keyword from *.cs files at all and map fully qualified class name to physical folder structure instead like java does ?

[bondsbw]

@bomzj I suggest opening up a separate proposal for the folder structure idea.