Added: LDM Notes for January 5th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-01-05.md

Agenda

• File-scoped namespaces

[HaloFour]

IMO where file-scoped namespaces are useful is in the 99.999% case where a file contains types (usually only one) within a single namespace. As such I don't think it would be overly restrictive if the language required that such namespace directives only appeared once and before other directives. I consider it more or less equivalent to Java package which is also limited in such a manner and has never been considered a problem. Anyone with more complicated requirements already has perfectly reasonable syntax that they can use.

[CyrusNajmabadi]

Humorously enough, I did the math, and the single namespace case is indeed the 99.99% case. So I am firmly on the: solve that case and do not handle the rest.

[canton7]

I'm excited for this one! I think it will make a significant change for the better.

My vote goes on allowing one top-level namespace per file, but additional "traditional" braced namespaces may be added if desired, which are not nested inside the top-level namespace.

Any code, including classes, "traditional" braced namespaces, and top-level statements, must appear after any top-level namespace. I can imagine the namespace declaration getting lost easily if it appears after any code.

usings and a top-level namespace may appear in any order.

namespace Foo;

void TopLevelMethod() { }

class Bar { }

namespace Foo.Baz
{
}

class Qux { }

[333fred]

I'll be honest: I look at that code example and it deepens my conviction that we should absolutely not support traditional namespace declarations combined with this feature, or support more than one of these per file :). I don't know what namespace Qux is in, or whether you have Foo.Baz or Foo.Foo.Baz.

[canton7]

Fair, glad it helped in some way 😄

Reading it back, I'm inclined to agree. No embedded namespaces: I was already against more than one top-level namespace per file

[IndianaGary]

I hate to admit it but these kinds of language changes are rapidly making C# a write-only language. Reading it is becoming increasingly difficult.

[huoyaoyuan]

I don't want to see much time is spent on this feature - it isn't such worthy.

[ufcpp]

namespace X;
class A {}
namespace Y;
class B {}

My expectation on them is X.A and Y.B. On the other hand, if they are X.A and X.Y.B, how is Y.B declared? like below?

namespace X;
class A {}
namespace global::Y;
class B {}

[CyrusNajmabadi]

how is Y.B declared?

It wouldn't be supported. There is no goal for this feature to support all possible scenarios.

[Richiban]

Would this also allow top-level statements to be namespaced? I imagine that most of the time it's a non-issue but I've noticed that top-level statements in C# 9 can only go in the global namespace, which is something I don't like.

This is not allowed:

using System;

namespace MyProject
{
    Console.WriteLine("Hello world");
}

Would this?

using System;

namespace MyProject;

Console.WriteLine("Hello world");

It feels like it should.

[canton7]

Interesting. The counter-point to this is that I don't like:

using System;

Console.WriteLine("Hello, World");
Console.WriteLine("More stuff");

namespace MyProject;

class Foo
{
}

class Bar
{
}

This hides the namespace MyProject, making it hard to spot. Good luck noticing that Bar is in a namespace!

[HaloFour]

I don't see a problem with the file-scoped namespace directive being used with top-level statements, but I think that affirms my position that it should be one of if not the first directives permitted in the file. It would similarly make no sense to stick the directive after a type declaration:

class Foo {
}

namespace Bar;   // IMO, should be a compiler error

[Richiban]

I agree; if it's present in a file it's got to be before any type declarations or statements.

[CyrusNajmabadi]

Would this also allow top-level statements to be namespaced? I imagine that most of the time it's a non-issue but I've noticed that top-level statements in C# 9 can only go in the global namespace, which is something I don't like.

There was open debate on this, with good points being made in both directions. My personal position is: start with them disallowed. They can always be allowed later.

This is not allowed:
Would this?

No, that would never be allowed. It's already restricted by the need for top level statements to go before all the other namespaces/class/type symbols.

[CyrusNajmabadi]

I agree; if it's present in a file it's got to be before any type declarations or statements.

This is how my specification has it. The grammar would be one of the following (depending on if we support top level statements or not):

#4073

Top level statements not allowed:

compilation_unit
    : extern_alias_directive* using_directive* global_attributes? (single_line_namespace_declaration | (statement* namespace_member_declaration*))
    ;

Top level statements allowed:

compilation_unit
    : extern_alias_directive* using_directive* global_attributes? statement* (single_line_namespace_declaration | namespace_member_declaration*))
    ;

single_line_namespace_declaration
    : 'namespace' qualified_identifier ';' extern_alias_directive* using_directive* type_declaration*

[MgSam]

In writing .NET code for 10+ years, the only times I've ever seen more than one namespace in a single file were when the file was code generated, and even then it was extremely rare. There is absolutely no reason to support multiple top-level namespaces per file, it just is a recipe for confusion.

FWIW, my original proposal for this issue from 2015 also was explicit in proposing that this should be disallowed.

[CyrusNajmabadi]

There is absolutely no reason to support multiple top-level namespaces per file

I personally agree. I actually did a measurement here across millions of files, and 99.99% were either single-namespace-single-type files, or single-namespace-multiple-type files. I've strongly put forth the positoin in the LDM that this ithe bread and butter case to support, and expanding out beyond that is not necessary.

[ufcpp]

the only times I've ever seen more than one namespace in a single file were when the file was code generated

I agree this but I have many source-generated codes in my company.

[erik-kallen]

But those obviously use the old syntax, which will continue to work. No need to change them

[qrli]

It seems LDM did not talk about the resolution of using in the case of file-scoped namespace. Are the usings supposed to be inside namespace or outside? Or you have consensus so no need to raise up?
That's a small thing but behaves slightly different, unfortunately. My personal wish would be to remove the small difference and the slight different way of doing the same thing, for file-scoped namespace scenario. It was also a style battle in early days, though now most code now put usings outside of namespace because of, maybe, Visual Studio defaults or Resharper.

[CyrusNajmabadi]

It seems LDM did not talk about the resolution of using in the case of file-scoped namespace. Are the usings supposed to be inside namespace or outside? Or you have consensus so no need to raise up?

They work exactly like normal namespace declarations. You can put them outside, or inside. They are resolved in the exact same fashion. My spec covers this :)

[CyrusNajmabadi]

That's a small thing but behaves slightly different, unfortunately.

That's absolutely by design. :)

My personal wish would be to remove the small difference

We will not be doing that. The goal of this feature is to hit the 99% case. And the 99% case definitely covers usings on the outside and usings on the inside.

[qrli]

Fair enough

[333fred]

For anyone following this issue, we discussed it again on January 13th: #4328.