Class declarations without curly braces

[ronnygunawan]

This idea is similar to #4348 but this is for class declarations. I want to declare classes without curly braces:

namespace ConsoleApp;
public static class HelperClass;

public static void WriteLine(string text, ConsoleColor color) {
    Console.ForegroundColor = color;
    Console.WriteLine(text);
}

with constructor, fields, and properties:

namespace Foo;
public class Bar;

public Bar(int field, int property) {
    _field = field;
    Property = property;
}

private int _field = 0;

public int Property { get; set; }

with nested classes:

namespace Foo;
public class Bar;

public class Baz {
}

This syntax will be very helpful for writing minimal APIs demonstrated in this ASP.NET Community Standup: https://www.youtube.com/watch?v=enAskgcF0c0

[CyrusNajmabadi]

This makes things very ambiguous. For example, this is already legal today: public record Foo(); Now it becomes less clear if ; terminates a type, or groups over the remainder of the file.

[calin-darie]

Wait, have you considered adding a keyword to clarify?

e. g. (but don't take it as the final proposal, just a start of a discussion)

fileScoped public record Foo();

There would be a compiler error if you try to have multiple such declarations in a file or if you don't start the line with the keyword (e.g. public static fileScoped... in a manner that would hide the keyword among access modifiers).

The keyword can be highlighted by the IDE so that is further pops out.

[BurkusCat]

this is already legal today: public record Foo();

Is this useful today? Are there not options such as:

• make file-scoped classes an opt-in language feature
• make that public record Foo(); line mean a file scoped record. For people who have used public record Foo(); in a file with other classes/records, they will get a compilation error and have to move it to its own file. Or, if they want to keep using multiple record/classes in a file they just change it to public record Foo() { }.

I feel like the reason to keep supporting public record Foo(); as it is today is not very compelling. There is more benefit to be had for more people by adding file-scoped classes.

[HaloFour]

Is this useful today?

It's legal today, which is the more important distinction.

make file-scoped classes an opt-in language feature

The bar for adding a dialect to the language is excruciatingly high.

in a file with other classes/records, they will get a compilation error and have to move it to its own file.

That is a breaking change, and the bar for doing that is similarly high.

Even without those considerations the language team has expressed that they're not interested in this feature, so they're very unlikely to consider changing other language features to accommodate it.

[BurkusCat]

I understand that breaking changes are usually avoided. If you take into consideration how few projects would be affected and that it isn't a silent breaking change (the compiler errors would be very obvious) I think the impact is definitely on the lower end. I think that would be in this feature's favour.

However, if no one in the team is interested in championing the feature then that is obviously a much bigger roadblock.

[333fred]

We explicitly considered this in the design for #137, and rejected it as something we're not interested in.

[AdamCoulterOz]

Single class per file is a very common c# practice, an obvious extension of file scoped namespaces, and is a reasonable question to ask. Saying it's "something we're not interested in" is a pretty harsh response. Better to just say "it was considered and rejected", pointing to the well reasoned justification (exactly what everyone wants to understand). Also using "we" in a way creating an "us and them", excluding real developers who use this open source language every day from language decisions isn't accurate.

[HaloFour]

Saying it's "something we're not interested in" is a pretty harsh response. Better to just say "it was considered and rejected", pointing to the well reasoned justification (exactly what everyone wants to understand)

Every proposal needs a well reasoned justification in order to be considered by the language team. Without a member of the team willing to champion the proposal and debate the design in design meetings no proposal will proceed further.

Also using "we" in a way creating an "us and them", excluding real developers who use this open source language every day from language decisions isn't accurate.

Fred is a member of the language design team and they are the arbiters of the language.

[CyrusNajmabadi]

is a pretty harsh response.

It's an honest response. The default state for the language is for it to not change. The default policy for all proposals is to not take them. A proposal needs a strong reason, with lots of value to be taken. So the onus is on the proposal to prove its worth, not for the language to have to prove it is not worth it.

As mentioned, we looked at this and found it very ambiguous and at odds with things we are very interested in doing in the language in the future. Those are not good things, and so we decided we're not interested in going this direction.

[Nefcanto]

I am coming from #8501. I read the arguments. I don't see how public record Foo(); is an obstructive reason.

If this change is difficult, one thing comes to my mind. Preprocessors. Or even code generators (as mentioned in the linked thread). When someone writes public class Something; and omits breakpoints after it, it's a clear signal that it should be preprocessed (the file content can be wrapped inside curly braces) or another class can be generated.

I might die and not see those days. But I can assure everyone reading this post that someday in the future, this feature will exist in C#, or it will go out of the industry. The reason? simplicity.

[spydacarnage]

@Nefcanto - it is personal preference, as it holds no value to me.

And this is C# - I see no reason for it to be dictated to by Python coding standards. If you want to use Python coding standards, use Python...

[HaloFour]

C# isn't attempting to "mimic other languages". It may find inspiration for features from other languages and paradigms, but the syntax must fit with C# syntax. What you call simplicity others call cluttered and unstructured. If C# were to start taking syntax inspiration from PHP, I would be the first to stop using it. IMO, PHP is an excellent example of a language that tried to evolve by accepting and jamming every proposal, with no thought towards consistency or future evolution. But, if that's your preference, feel free to use PHP.

[CyrusNajmabadi]

It'd odd to mention python @Nefcanto, as python mandates indentation as part of the semantics of their language. C# does not. Indentation is a stylistic concern you can choose to follow (or not follow) to your heart's content. If you want flat C# you can have flat C#.

Removing thousands of unnecessary indentations is a great objective value.

And yet Python does not do this for classes.

[CyrusNajmabadi]

I am coming from #8501

Source generators would be a good solution there. Note: source generators can nest code however you want it to be nested (including none at all). So you get a solution for your needs that also fits the style you want.

[CyrusNajmabadi]

It's about value.

We agree. We do not find this proposal to be substantively valuable. It also conflicts with things we think have a good chance of happening in the language.

[Nefcanto]

I just found this Never Nester video. I think the whole world stands on one side, and less nesting is better.

[HaloFour]

That has to do with the nesting of logic within a method, it has nothing to do with indentation in general.