Add top-level members proposal #9719
Conversation
|
|
||
| - Some members can be declared directly in a namespace (file-scoped or block-scoped). | ||
| - Allowed kinds currently are: methods, operators, extension blocks, and fields. | ||
| - Existing declarations like classes still work the same, there shouldn't be any ambiguity. |
There was a problem hiding this comment.
Top-level statements can co-exist with type declarations, but must come first. Is there a similar rule for top-level members?
Would such types be in the namespace or nested in the TopLevel type? From the spec it should be in the namespace (since types are not allowed as top-level members), but that's surprising. So it may be better to just disallow them...
There was a problem hiding this comment.
That's a good question, I will add it to the list. But I don't find the behavior surprising, consider that you have an existing code like
namespace N;
class C;and you decide to add a top-level member, for example
namespace N;
int M() => 42;
class C;that could be disallowed but if it's allowed it seems natural that the class remains directly in the namespace as it was before.
There was a problem hiding this comment.
if it's allowed it seems natural that the class remains directly in the namespace as it was before.
That's arguable, but not obvious. What if I sandwich the type?
namespace N;
int M() => 42;
class C;
int M2() => 42;
It doesn't seem obvious why M() and M2() are in N.TopLevel, but C is directly in N
| - Some members can be declared directly in a namespace (file-scoped or block-scoped). | ||
| - Allowed kinds currently are: methods, operators, extension blocks, and fields. | ||
| - Existing declarations like classes still work the same, there shouldn't be any ambiguity. | ||
| - There is no ambiguity with top-level statements because those are not allowed inside namespaces. |
There was a problem hiding this comment.
It's a bit unfortunate that top-level members only be allowed inside namespaces. It seems irregular. But it does help make things unambiguous... Probably worth discussing more
| - Cannot be addressed from C#, but has speakable name `TopLevel` so it is callable from other languages. | ||
| This means that custom types named `TopLevel` become disallowed in a namespace where top-level members are used. | ||
| - Usage: | ||
| - `using NS;` implies `using static NS.TopLevel;`. |
There was a problem hiding this comment.
If I already have a namespace "N" with a type named "TopLevel" in metadata, will using N; gain the new behavior?
There was a problem hiding this comment.
Hm, good question. Perhaps there should be some attribute akin to [Extension].
|
|
||
| ## Open questions | ||
|
|
||
| TODO: What parts of the design are still undecided? |
There was a problem hiding this comment.
The rules for name conflicts should probably be spelled out.
For example, it seem as if the following declarations would be in conflict, due to how they are represented in the language
namespace NS;
int Foo;
class Foo { }
Markdown
Just an outline for now if anyone has any comments before I start filling in details.
cc @jaredpar as the LDM champion for this feature