[Proposal]: Flexible placement of module imports, static class imports, aliases (i.e. all using statements,) and file-scope namespace declarations.

[Kile-Asmussen]

TL;DR: It would massively improve ergonomics for reading code in non-IDE settings and obey principle of least surprise.

I don't think it is controversial to state that the most important part of any given C# code file is the class declaration.

I propose that the most important parts of a code file should be at the beginning of a file.

The import list is arguably among the least interesting parts of code files, and yet by the C# language specification we are forced to put it at the beginning. This means, if we view code as a form of prose, every single code file buries the lede, which is considered bad practice in prose writing. Also, every IDE worth its salt will hide the import list from view and automatically manage imports: it is not even important enough for most developers to directly look at 95% of the time.

(For other languages like Python and C, there are technical limitations forcing import lists to be at the beginning of the file, but C# is a modern compiled language with true modules.)

Import lists at the beginning of file also has practical consequences: the command-line utility head gives no insight at all into what a given code file defines and it means that opening a code file in a simple text editor always requires scrolling 10-20 lines down.

C# 12, unlike Java, allows multiple top-level declarations in a code file. using-statements and file-scoped namespace declarations appear to be top-level declarations, but are in fact not. They are special things that must go at the beginning of the file, which violates the principle of least surprise. Furthermore Java actually allows end-of-file imports, while languages like Rust is extremely flexible with imports. (Regrettably, most Java IDEs still put imports at the top.)

Forcing imports to be at the top of the file is, fundamentally, an aesthetic choice made by the language designers. There is no reason to enforce with compiler errors what should be a code style option.

[HaloFour]

Furthermore Java actually allows end-of-file imports

I just tried this with Java 8 and Java 21 javac and neither allow end-of-file imports: error: class, interface, or enum expected

IMO, directives that affect the scoping of types throughout the source file are the most important parts of that source file, and they should be front and center. Unlike Java, there is no direct relationship between a C# source file and any types declared within that file. The C# language and compiler do not share your opinion that a single class declaration is the most important part.

[Kile-Asmussen]

Well, it would appear I am mistaken about java, but I will dispute your judgment of what is most important:

"Programs must be written for people to read, and only incidentally for machines to execute."

&mdas; Abelson and Sussman, Structure and Interpretation of Computer Programs

A compiler and a language spec does not decide what is "important" it just decides what is. It is a computer program, it does not have opinions, only specification and implementation details. The language designers, being human beings with opinions, decide what is important, and then put it in the spec and implementation.

I can tell you quite confidently that there is no technical limitation requiring that import statements go at the top of the file, as is evidenced by other compiled languages such as Rust. It is an aesthetic choice made by the original language designers; effectively an enforced code style choice.

I think this judgment is worth revisiting in the interest of potentially improving readability, and at the very least it is a judgment that should be relegated to code style enforcement tools, rather than compiler specification.

I appreciate your input that you think scoping of symbols for a file is more important than the class specified within, but I do not agree. Last I checked C# is an object-oriented language, rather than an import-oriented language ;) More seriously, this is also evidenced by the fact that your IDE hides your import list under a fold and automatically manages it for you: it is not important enough for you to even look at most of the time.

[HaloFour]

I can tell you quite confidently that there is no technical limitation requiring that import statements go at the top of the file

Indeed there isn't. But that doesn't mean that the compiler should flip things around for the sake of everyone's stylistic preferences. The placement of the imports does affect their behavior, as evidenced that they work differently based on whether they are declared within the scope of a namespace.

The language designers, being human beings with opinions, decide what is important, and then put it in the spec and implementation.

That includes how they feel the language should be used. They intentionally based the language and some of the semantics on how C++ is expected to be structured, including semicolons, curly braces and namespaces at the top of the file.

Given C# is 22 years old, and this is the first time someone has suggested burying imports at the bottom of the source file, I doubt it's likely to be considered simply because there is no ROI for doing so.

That's just my opinion, tho.

Last I checked C# is an object-oriented language

Yes, C# is an object-oriented language. But C# has no opinion regarding how those objects are declared within source files, as evidenced by the fact that there is no 1:1 relationship between objects and those source files, or their layout in any given project. You can invoke the compiler without source files at all.

[CyrusNajmabadi]

As one of the lang designers, I can say that I consider imports one of the most important things about a file. The imports tell me immediately about the domains a particular file will be using. They also immediately prime me on things like complexity.

I review a ton of code (often a dozen or more prs per day). The usings are critical, and something I look to immediately when examining a pr. I can often tell immediately when something has gone awry just by seeing what usings were added or removed from a file.

--

Finally, using placement very much affects semantics. We could not move these to the bottom of the file trivially as we would no longer be able to get the semantics we have today. Any proposal here would have to address how file-scoped namespaces work and would have to provide a way for the usings at the bottom of the file to be either inside the namespaces or outside of it.