Proposal: single-type files

[lostmsu]

This is related to "File scoped namespaces" proposal #137, I just wanted to track it separately (though IMHO, they both should be implemented in the same iteration).

Basically, the idea is to remove two indentation levels, that unnecessarily appear in C#<=7: namespace and class. Here's the example syntax I'd be looking for:

using System;
using System.Collections.Generic;

public class MyCompany.MyLib.MyClass<T> where T: IMyInterface<T>;

bool good = true;

public override string ToString() => $"is good: {this.good}";

We can decide if usings will be treated as being inside MyCompany.MyLib or outside. I'd prefer the first one, but the second option would be less of surprise for newcomers.

Same code without the feature for comparison:

using System;
using System.Collections.Generic;

namespace MyCompany.MyLib
{
    public class MyCompany.MyLib.MyClass<T> where T: IMyInterface<T>
    {
        bool good = true;

        public override string ToString() => $"is good: {this.good}";
    }
}

[iam3yal]

@lostmsu The other proposal is much more sensible in my opinion because it tries to reduce the nesting created by namespaces but this looks like a complete new language to me. 😆

Edit: Rephrased.

[lostmsu]

@eyalsk same for me. However, I think its because we all so much used to the two levels of indentation, that their absence feels completely alien.
I can see this helping a lot in diff viewers though.

[iam3yal]

@lostmsu Can't see the benefit of this but each to his own I guess. :)

[lostmsu]

@eyalsk open this on laptop (random pull request from my browsing history): https://github.com/dotnet/roslyn/pull/20269/files
Note how many lines in C# code are wrapped in diffs because line is too long. This would reduce this effect. In general, it will be easier to program on laptop due to screen space restrictions.

[jnm2]

I am completely on board with including namespace and declaring type name inline with the class name, but I really am not liking the more drastic effect of making it look like the class declaration has ended but then including the following declarations inside it. I don't like it any more than I liked it in the using (...); statement proposal.

[lostmsu]

@jnm2 that makes sense. Unfortunately, some token is needed there to avoid ambiguity.

Perhaps it's better to replace ; with =>. Although that would make indentation of => inconsistent with indentation in functions.

Another alternative is to use some existing keyword like is in place of ;.

But I am actually against that. Somehow this is similar to using System;. Despite using not being a declaration everyone knows its scope is till the end of file. And unlike using statement proposal you mentioned, in this case it is guaranteed to be the only statement like this in the file, and file will always start with it.

[jnm2]

Despite using not being a declaration everyone knows its scope is till the end of file.

Same with variable declarations; and yet my point is, in neither case do these statements actually contain the following declarations or statements. With using System;, System does not contain what follows. With int x;, x does not contain the following lines. It's more like an attribute (in a limited way) in that it applies to the following declarations and statements, rather than containing them.

[MkazemAkhgary]

This is not same

namespace MyCompany.MyLib
{
    public class MyCompany.MyLib.MyClass<T> where T: IMyInterface<T>

I expect MyCompany.MyLib.MyCompany.MyLib.MyClass, why making c# syntax, a c++ like syntax? 😄

Instead I would say namespaces could be omitted inside class name. so

public class MyCompany.MyLib.MyClass<T> where T: IMyInterface<T>
{ // notice we didn't remove body.
}

would be equal to

namespace MyCompany.MyLib
{
    public class MyClass<T> where T: IMyInterface<T>
    {

IMO replacing body of class semicolon is not good suggestion. that's 👎 part but having namespace with class name for me is 👍 and doesn't make strange change in current syntax. (it saves 3 lines for good sake.)

[lostmsu]

@jnm2 you are appealing to consistency, but that consistency does not really exist, and two different kinds of using statement is a good demonstration of that. Note, that using(x = new X()) has a body, while using System; just implicitly continues until the end of scope.

P.S. I intentionally did no say using(var x = new X()), because then you could argue, that using(...) defines something. Well. It does not! Actually, it just introduces a lifetime scope for an object. In that sense using System; also introduces visibility scope for namespace members.

[stepanbenes]

This syntax may collide with the proposed syntax for records.

[fanoI]

OK to remove namespace indentation but I prefer to leave the '{' for the class body, I'll interpret your example as: MyCompany.MyLib.MyClass<T> is an empty class, bool good is a global and the rest are "free functions"...

This version of C# seems more a scripting language that a "true" programming language.

[jnm2]

@lostmsu I don't see any inconsistency. Technically there's one using statement; the namespace import thing is usually called a directive not a statement– but more importantly, the two things are not related to each other. They could have been called foo and bar.

Things that contain other things do it via blocks and indentation. Classes contain declarations, block statements contain statements, etc. There's a special exception for blocks containing one statement but no exception for blocks containing one declaration, but that's not what you're asking for either.

[ghost]

How would nested classes be handled? Nested classes are more common (and more useful) than nested namespace.

Nor am I fan of working in a codebase where it's impossible to add a new class to an existing file even on a temporary (i.e. pre-PR) basis. When I'm bringing up a big new feature with lots of new classes, it's just much more efficent to throw them into the file I'm working on during the bringup and segregate them in waves (during those otherwise unproductive 15min time-slices between meetings and a lunch or whatever) after the big thinking is done and I'm sure I actually want the classes.

[jnm2]

Nor am I fan of working in a codebase where it's impossible to add a new class to an existing file even on a temporary (i.e. pre-PR) basis.

^^ So much this.

[jnm2]

How would nested classes be handled?

I really (and I mean terribly) wish I could do this:

SomeClass.cs:

partial class Some.Namespace.SomeClass
{
    // ...
}

SomeClass.SomeNestedClass.cs:

class Some.Namespace.SomeClass.SomeNestedClass
{
    // ...
}

[HaloFour]

@DavidArno

Hi. I'm a Java developer. I don't put newlines after closing braces. Now you've met one. 😜

My point is that you choose your verbosity. The language only requires two characters to establish the scope within a type. Newlines and indentation is all up to the developer.

You also demanding that F# nix the indentation that is required for everything? Even without the braces I doubt too many developers would embrace the idea of not enclosing the members in some kind of scope denoted by indentation.

[DavidArno]

@HaloFour,

Hi. I'm a Java developer. I don't put newlines after closing braces.

Um, I was talking about opening braces. I suspect this a simple typo on your part, but hey, if cheap points are offered... 😉

My point is that you choose your verbosity. The language only requires two characters to establish the scope within a type. Newlines and indentation is all up to the developer.

Technically, yes. But to mind at least, convention trumps personal preference a lot of the time. That's why, when writing JavaScript or Java, I follow the K&R brace layout. For C#, I use Allman. I prefer the latter, but I follow the conventions of the former two languages over my own preferences.

You also demanding that F# nix the indentation that is required for everything?

F# is an odd one in this regard. Declare a module (which, as far as I know, is just a abstract final class in .NET, or "static" in C# terms) and no indentation is required for the functions therein. Declare an interface or class/struct though and indentation must follow that =. That inconsistency is one of the things I think F# got wrong.

[HaloFour]

@DavidArno

A newline after the opening brace? I've never seen that. Java devs seem to prefer fairly dense code, to the point of having closing brace, keyword and opening brace all on the same line, e.g.:

if (foo) {
    doFoo();
} else {
    doBar();
}

[lostmsu]

@HaloFour newline after opening brace is default in IDEA for method bodies AFAIK. At least I've seen it a lot. Not for IFs.

I also prefer opening brace on the same line btw. Saves vertical space.

I am sad to see people downvoting feature that brings physically measurable advantage over their idea of language consistency. I fail to see how anyone even with least experience and involvement could not comprehend and remember that class ...; does not indicate empty body, but a "directive".

[iam3yal]

@lostmsu

I am sad to see people downvoting feature that brings physically measurable advantage over their idea of language consistency.

C# is a curly brace (or bracket) language not because the "userbase" chose it to be but because the designers of the language chose it and we followed partly because the syntax is similar to what we are accustomed to, most notably the curly braces so the idea wasn't ours to begin with.

You see that as a benefit some of us see that as a fundamental change to the language that we're not in favor of or think that it's too extreme and this is the reason for the downvotes.

p.s. I really wouldn't mind it either way so I removed the downvote, I still think it's a fundamental change to the language and one that I probably wouldn't use but don't care whether others will.

[sharwell]

💭 Java approaches this functionality in a slightly different manner:

• The package clause is written in "statement" form instead of "block" form
• Various IDEs expose an option to not require indentation for top-level members of a type

If this approach (both options) were applied to C#, the resulting code might look like this:

using System;
using System.Collections.Generic;

namespace MyCompany.MyLib;

public class MyClass<T> where T: IMyInterface<T>
{
bool good = true;

public override string ToString() => $"is good: {this.good}";
}

💭 My biggest concern overall with this proposal is the confusion and/or limitations that may result from the placement of using directives. In the current C# language, using directives have slightly different semantics when they are placed inside a namespace declaration instead of outside it.

💭 I also have a concern related to the class Namespace.Type { } form:

• If you only allow the dotted names for non-nested types, then some benefits of single-file types will not be achievable for nested types in a partial class
• If you only allow the dotted names for nesting types, then you would not be able to remove the separate namespace declaration line
• If you try to allow something like partial class Namespace.Outer.Nested { }, then the behavior of the single-file type becomes dependent on other files (is Outer a namespace or a type? what about Namespace?).

[jnm2]

If you try to allow something like partial class Namespace.Outer.Nested { }, then the behavior of the single-file type becomes dependent on other files (is Outer a namespace or a type? what about Namespace?

Absolutely it's dependent, and I like it that way. Any time you have partial in the class definition, you know you are depending on other files in the first place.

[AustinBryan]

I think it's a good idea to remove the namespace indents, but I would feel like everything I'm writing is in some global scope without the class. It feels like I'm writing in C or something 😐

[GeraudFabien]

It would feel like this at the beginning. But has everythinks in any language you have to take time to adapt. And i don't thinks it would be long.

It would help mitigate some issue :

• When you open a a source file on half or else of you're screen it's really hard to read since all line are by default indent
• Enforce the fact the file should only contain one class (Even if we can support nested class we can't support two class not nested with this system). (Personnaly I'm on the side not to support nested because it would simplify avoid a lot of problem)
• When you have a big file sometime it's hard to keep track of closing bracket. Without a level a not needed closing bracket will directly show the right error near the right place.
• When a dev is too lazy and do multiline string it would remove a lot of useless space in the final string.

The main problem for me is that it must be forbidden to write the file scope class sentence affter the first method/Property/field/... is specify.

[DavidArno]

It's interesting revisiting ideas like this years later.

Back then, I was really keen on that idea. Since then, the language has added support for file-scoped namespaces. But it has also added top-level statements. To my mind, that latter feature changes this one from one I was keen on to one I'm strongly opposed to:

// Not a class, just some top level statements
namespace MyNamespace;

string field = 1;

void Bar() => field = 2;

string Foo() => field;


// Is a class
namespace MyNamespace;
class SomeClass;

string field = 1;

public string Foo() => field;

void Bar() => field = 2;

The only clues that one is a class and one isn't is that class line and that Foo is marked as public in one and not the other. When a file is possibly hundreds of lines long, that sort of thing is too easily missed.

[lostmsu]

It might be better to have class MyNamespace.SomeClass without the namespace directive.

Besides, I think top-level members are only allowed in the file that is the program entry point, which is usually hard to miss.

[CyrusNajmabadi]

It might be better to have class MyNamespace.SomeClass without the namespace directive.

This woudl be highly ambiguous with other proposals around allowing that for nested types. Paging @jnm2

[scottmwyant]

I like the proposal and think it aligns nicely with file level namespaces. The sample you shared is nasty but I think you’d limit it to either top level (which is implied class Program) or a single class declaration ending with ;. Nested classes would use conventional braces.

[jnm2]

Yes, class A.B.C { } would have to mean class C { } nested inside partial type B nested inside partial type A. I think @333fred or others were commenting in Discord a long while ago on how it would be unworkable for these to be namespaces.

I do have a use case for class Outer.Nested { } related to what happens to source control line history and lack of rename history if you refactor a nested class to a top-level one or vice versa. I'm planning on drafting a proposal.

[SpocWeb]

I would rather swap Top-level statements with file-scoped classes,
because for each Program you write, you also write hundreds (or thousands) of classes.

[333fred]

See also the answers for #4722, where Cyrus and I laid out why this won't happen.

[lostmsu]

The syntax is just an example. Semicolon can be replaced by a keyword. is, with, or any other token really.

[333fred]

In general, we're not trying to remove the braces here. We find it visually ambiguous and not worth the effort, regardless of what token ends the class line.

[CyrusNajmabadi]

The syntax is just an example. Semicolon can be replaced by a keyword. is, with, or any other token really.

Can you show examples of what you mean? As this proposal is entirely about syntax, we would need to see what form you mean here. Thanks!

[lostmsu]

I mean just take the original suggestion and replace semicolon after the class title with anything. E.g.

using System;
using System.Collections.Generic;

public class MyCompany.MyLib.MyClass<T> where T: IMyInterface<T> with

bool good = true;

public override string ToString() => $"is good: {this.good}";

[Mindstyler]

So C# recently introduced a file keyword for file scoped methods, etc ...
And I was thinking maybe this could also be used to remove ambiguity in this use case by being added as another explicit accessibility modifier.
AKA something like

public file class MyClass;

Looking forward to your thoughts.

[Mindstyler]

Well yeah, but it's use could be extended so it could be used here.

[333fred]

No it couldn't. It already means something when applied to types. That something is not this.

#928 (comment) as well, where I pointed out that the LDM has explicitly rejected this concept.

[Mindstyler]

Ah damn. I wasn't aware it's actually already a valid modifier for types.
I don't mind writing the normal classes, just thought that this might've worked.

[calin-darie]

file may not be an option, but there could be another keyword, right?

[calin-darie]

Also maybe we should force the keyword indicating file scope as the first keyword, so that it stands out more

[pelletburner]

I agree with this proposal, but the ";" at the end of the class declaration needs to go and be replaced with something else.

Although I understand that this is there to put it in line with the namespace declaration syntax.

[Eli-Black-Work]

A colon (:) seems more intuitive, to me 🙂

[pelletburner]

A colon (:) seems more intuitive, to me 🙂

Yes, was thinking the same.

";" is so "final", to me this implicates that "something is done".

[UniqeId6542]

I want to agree, but...

namespace MyNamespace; has the rest of the file under the namespace
using System; has the namespace available for the rest of the block / file
using (MyDisposable d = new()); has d available for rest of the block and dispose it after
int x; has x available for the rest of the block

In my head, I want a statement to be more 'isolated' (a = b + c;) But maybe my concept of a statement needs broadened.

[InCerryGit]

It looks great, it can save screen space. Is there any progress on this?

[saint4eva]

Kindly get bigger monitors if you need more screen space.

[Eli-Black-Work]

@DavidArno Would public class MyClass: work? (Colon instead of semicolon)

[InCerryGit]

Kindly get bigger monitors if you need more screen space.

Many people work with laptops, so the screen size is limited.

[DavidArno]

@DavidArno Would public class MyClass: work? (Colon instead of semicolon)

It could, but as I said before, the language team has made it quite clear they aren't interested in this feature, eg see here and here. It's unclear to me why they haven't just posted a "We won't ever do this" comment and then marked the discussion as answered as it is misleading as it stands and appears the topic is still up for debate.

[Eli-Black-Work]

@DavidArno Thanks, I missed that the first time around 🙂

I admit, I do like that the C# language designers leave discussions like this open, rather than locking them, so that there's an opportunity for continued discussion.

[DeminAO]

it might look like this:

• the definition of the structure (class, interface, etc.) has no scope - the entire file is the scope of the structure
• the directory path of the structure is the definition of their namespace
• by default, it would be possible to omit the class definition and consider the file name as its name (it would be possible to define the type of structure (class, enum, interface, record) in the file name)
• for the simplicity of defining the constructor, one could use ".ctor". Then there would be no need to worry about updating the file name and constructor definition inside
• or completely abandon constructors in favor of field attributes, if we are talking about injecting services from a container. For example, so: inject ISomeService someService

[DeminAO]

and then, using globalusings, omitting the namespace definition, removing the class brackets, removing the constructor, we can get clean code in which only logic is concentrated.

example:
.proj
-- PeopleModule
-- -- ContextRepository.cs
-- -- Domain
-- -- -- PeopleDbContext.cs
-- -- -- Entities
-- -- -- -- Person.cs

// PeopleDbContext.cs

implements DbContext;

public DbSet<Entities.Person> People { get; set; }

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
	// configure people
}

// ContextRepository.cs

public interface IContextRepository
{
	Person GetPerson(int id);
}

implements IContextRepository;
inject Domain.PeopleDbContext _context;

public Person GetPerson(int id)
{
	return _context.People.Find(id);
}

[DeminAO]

and at controller:

.proj
-- PeopleModule
-- -- PeopleController.cs

implements ControllerBase;

inject ContextRepository.IContextRepository _repository;

[HttpGet]
public ActionResult<Person> GetPerson([FromQuery] int id)
{
	return Ok(_repository.GetPerson(id));
}

[DeminAO]

about constructors

public PeopleDbContext(DbContextOptions options) : base(options) { }

overriding a constructor in a child class could be hidden from the developer's eyes and implemented if the developer did not add it. That is, the entry above could be omitted

[AndreLeria]

I don't think anyone suggested this yet: why don't we couple the namespace declaration with the class declaration?

namespace MyNamespace.MySubNamespace with
class MyClass : IWhatever;

In which case the namespace (...) with would mean this is a single-type file. Then add a newline before or after the with keyword when formatting.

[Mike-Logit]

Despite the controversy around this feature, I agree that with makes the most semantic sense and it also fixes the issue of visually identifying what's going on from a code review perspective. If this feature were to be added, I'd vote for this approach.