Top-level members

[jjonescz]

Proposal: #9719 (markdown)
Champion issue: #9803

[julealgon]

I'm still surprised it took so long to get to this considering all the work done for Program.cs.

Will definitely help with language adoption and may be useful in some enterprise contexts too.

[Richiban]

This is a loooong-requested feature, and I am surprised (but very happy!) to see it being considered since I was sure the discussion was closed as "Likely never" the last time

[Richiban]

Copying in the link to the markdown document: https://github.com/jjonescz/csharplang/blob/tlm/proposals/top-level-members.md

[jjonescz]

Thanks, added to the OP

[Richiban]

I think this is a great idea, but I have a few concerns with the proposal:

I don't think fields (or auto properties) are a good idea (certainly not for the first release; once out in the wild maybe my concerns will be assuaged). Global mutable state that floats around outside of a class is bad juju, in my opinion; it's fine for methods (which will become 'functions') but allowing state will just encourage people to start using files as file-scoped classes.

Regarding mixing type declarations and top-level members in the same file: it feels like this should be allowed but there's a question about how it gets lowered; namely are the declared types nested inside the implicit type? I'd say they shouldn't be, otherwise adding a member to a file would cause the declared types to "move", perhaps disappear entirely (if their visibility is left to the default).

[julealgon]

Global mutable state that floats around outside of a class is bad juju, in my opinion;

I understand your concern, but this shouldn't be up to the language to "protect" the user. I think the functionality being orthogonal is more important than making these "best practice decisions" at the language level.

Besides, global state for something that is simple enough is totally fine. By enforcing "enterprise patterns" on the language it just makes it less flexible and less intuitive overall.

[KennethHoff]

Shared mutable state is the source of a huge number of errors; especially with parallelization in the picture. I don't believe that justifies artificially limiting the feature however

[mattwar]

How does this exist differently than the existing top-level members that are considered locals to an implicit constructor of the Program class?

[jjonescz]

Currently a top-level void M() { } or int x = 123; already means something, and this proposal seems to change that meaning.

The new meaning only applies if you put them in a namespace (which is currently not possible), so existing code wouldn't change.

[HaloFour]

I see. That makes sense. Thanks!

[RikkiGibson]

I think this difference has been nagging at my brain a little bit. The top-level of a file is a global namespace. So it just feels weird for it to not be able to do certain things that the explicit namespace can do with this feature. I'm not sure yet whether I consider that a real problem or not.

[HaloFour]

I can see an argument that folks would want to use this feature without needing namespaces, too.

[jjonescz]

I can see an argument that folks would want to use this feature without needing namespaces, too.

I guess we could allow that. The presence/absence of non-function top-level statements would determine whether it's top-level-statements Main, or the new top-level members. The only "breaking change" scenario would be if you had only local functions as top-level statements (but that's not a useful thing to have today).

EDIT: Actually there would be a problem of how to bring them to scope (there is already a bullet point under Alternatives for that).

[Richiban]

I'm copying a comment I made on the PR because perhaps that wasn't the best place to put it:

(With respect to what happens if you mix top-level members and types in the same file).

My mental model of how this should work goes like this:

Rather than thinking "If this file contains top-level members then lift the contents of the file into a generated class" I think "For each declaration in this file, if it's a member, then lift it into a generated class".

So

namespace N;

void M1() {}

class C1 {}

void M2() {}

class C2 {}

void M3() {}

becomes

namespace N;

partial static class TopLevel
{
    void M1() {}
}

class C1 {}

partial static class TopLevel
{
    void M2() {}
}

class C2 {}

partial static class TopLevel
{
    void M3() {}
}

rather than

namespace N;

static class TopLevel
{
    void M1() {}

    class C1 {}
    
    void M2() {}
    
    class C2 {}
    
    void M3() {}
}

[colejohnson66]

I confused about this proposal. Sure, C++ and Rust support them, but the LDT’s consistent argument to this feature through the years is “using static exists. Use it.” Why now?

I’m not against it. Just wondering “what changed?”

[Richiban]

I think there's been a movement in the last few years in the LDT that they should cater more to the features that users expect to exist, coming from other languages.

C# and Java are kind of alone in the fact that they don't let you simply declare a method on its own and then call it from elsewhere in your program; they make you wrap it in another construct (a static class) first. You must always reference the function with its class name as C.Foo() unless you use a special kind of import (using static N.C).

Although this is the way it's always been for C#, you've got to admit it is weird (and decidedly not beginner-friendly). Coming from OOP principles I'm not sure I think that static class even really makes sense as a concept; they were introduced as a kind of workaround for the fact that C# doesn't allow free methods or have the concept of modules.

So, I support this proposal, although whether or not it's worth the dev time is a decision for the design team.

[ufcpp]

Just wondering “what changed?”

I guess file-based programs are a very significant factor.

[jjonescz]

using static exists. Use it

Sounds analogous to "Program { static void Main() { } } exists - use it," yet we added top-level statements. Many language features are about removing boilerplate.

[TahirAhmadov]

Yes, I definitely think beginner friendliness is a good idea. Doesn't really hurt the "professionals", and makes the language easier to get into.

[RikkiGibson]

To me, extensions are what has moved the needle here. I think at minimum we should do something to allow an extension to be declared in a namespace. The other member kinds I am more ambivalent about at this moment.

[En3Tho]

Are there examples of code that would benefit from this so much? I fail to see how this is better than "global using static ...".

I think if user specifically wants members of some static class to be discoverable in ecope of namespace then a simple attribute similar to F#'s AutoOpen would suffice.

[Richiban]

This is all about making C# more beginner-friendly and making the language work in way that those familiar with other languages expect. It's also closing the gap between top-level statements in the program entry file and the rest of your program.

As an aside I support this feature on that second point alone; C# has long had a bit of a problem with features that "fall off a cliff", where you've written code with one form but now you need to do something but the languages says "Sorry, you're going to have to use a different form if you want to do that". So they're addressing the auto property case with the field keyword and now they're proposing tackling the top-level statements case with this (where you can start writing a C# program with top-level statements but, as the point you want to split your Program.cs file up because its grown you now have to use different language constructs in order to do that).

[jjonescz]

"global using static ..."

You seem to be focusing on the consumption side. That indeed doesn't change much (you still need a using) and hence that's not the motivation for this feature. The motivation is the declaration side. For example, consider extension members - you won't need to declare them in (otherwise useless) wrapper static class anymore.

[UniqeId6542]

If the main point is to make C# more beginner-friendly, then the idea is to reduce code overhead?
So, class-statements could accomplish the same thing - with potentially less confusion?
Currently, C# supports file-scoped namespaces:
namespace MyNamespace;
So, the same could be done for classes:
class MyClass;
Or, combine the two:
class MyNamespace.MyClass;
Since it seems like the namespace line will still be required with this proposal, then declaring the class the same way doesn't change the overhead. But class-statements also don't change the idea that methods are part of classes nor requires a compiler generated class to be made.

[CyrusNajmabadi]

class MyClass; is already legal code with meaning today. We can't change that.

[jjonescz]

This is a good callout, thanks, I will add it as an alternative to the proposal. Although it's only half of the proposal, other half is at the use site where your suggestion would need using static MyNamespace.MyClass whereas with top-level members it would be enough to have using MyNamespace.