[Proposal] Inline type declaration without curly brackets

[IDjinn]

Proposal

Currently we need declarate types using curly brackets even when is not used...

    public class SomeCustomException : Exception { } // Not used
    public class AnotherCustomException : Exception
    {
        public AnotherCustomException(string message) : base(message) { } // Not used
    }
    public interface IFoo { /*...*/ }
    public interface IBar { /*...*/ }
    public interface IFooBar : IFoo, IBar { } // Not used

I propose be able to delcare types without brackets, just using semicolon.

    public class SomeCustomException : Exception;// <--
    public class AnotherCustomException : Exception
    {
        public AnotherCustomException(string message) : base(message);// <--
    }

    public interface IFoo { /*...*/ }
    public interface IBar { /*...*/ }
    public interface IFooBar : IFoo, IBar; // <--

Currently records support this kind of declaration, as @DavidArno explains in #5513 (reply in thread)

    public record SomeRecord; // ok
    public record AnotherRecord(String Str); // ok

Pros

• Simplify type declaration
• Extends same type declaration already availible on records to class
• Legible and simple

Cons

• ...

Extra

Maybe also could make even simple derived class with simple sintax.

    public class AnotherCustomException(string message) : Exception(message);

[Rekkonnect]

Especially for interfaces, they are suffering the lack of this feature while there's so many cases of declaring purely decorative interfaces.

I remember this being discussed somewhere else too. And there also is some discussion about simplfying empty constructor declaration. Spoiler alert: many are whining that "it's just 2 characters, why bother so much".

[CyrusNajmabadi]

Every feature above has to be validated and tested for those forms. We have to doc all of this. We have to do the design work to determine if this would impact future design work. For example, if we wanted this syntax to mean something else in the future. We'd now not be able to if it were now purposed to mean this.

[DavidArno]

It is extremely difficult to imagine a situation where the lack of { } in the third case below would mean a different thing to the first two cases as it would be deeply confusing to any developer trying to fathom those two meanings:

record X;
record class Y;
class Z;

Yet the first two are valid syntax and last isn't. You already had to document the first two cases. You had to already have done the design work to determine if allowing { } to be dropped if record is present would impact future design work. By not also supporting the last case, you've simply created the need to do that work all over again a second time.

However, all is not lost, for primary constructors provide the motivation to revisit this. Assuming class Z(); will then be valid, it would create inconsistency and thus confusion with users were class Z; also not supported. And having changed the language to allow class X; and struct X;, it would seem churlish to not also support Interface IX; So I'm sure, @alfasgd, you can look forward to the team supporting this proposal in the next year or two. Maybe. 😉

[CyrusNajmabadi]

@DavidArno every feature needs to be validated and we have to make sure this will be the case and will not end up being a problem in the future. I recall you getting unhappy in the past with decisions you felt were rushed, so I imagine you are very cognizant of the need to be careful, take time, and think through these problem spaces.

[DavidArno]

@CyrusNajmabadi. Absolutely. Carefully thought through decisions is a good thing and I'm generally supportive of the team on that, even if I don't always agree with the decisions made.

One just needs to be mindful that this approach can lead to too much caution at times making these "easy wins" too hard to do. This proposal would result in one of those small but deeply satisfying changes to the language that put a smile on my face, so it would be nice to see it happen as part of the primary constructors work.

[IDjinn]

You guys are attacking each other but not focous in the proposal...

First: this proposal is for minimum change, and I think it's hard you say you will break next future design doing that because this feature already exists. (PS: I don't know how it works, but that is what it sounds like to me...)
Second: I hadn't thought about class Z; and record X; without params but it's just another example why it shouldn't be painful do this feature.

[IDjinn]

Proposal updated, renamed class declaration to type declaration (now interfaces is in proposal) and new example class derived declaration with simplified constructor (flagged as extra, beacause i'm not sure if it need be a new proposal)

[TahirAhmadov]

I don't see how saving literally one keystroke is valuable enough to change the language for it.

[IDjinn]

Thank you for reply, yes it is not big change but have its own value. With the extra example we could really reduce syntax need to do same job.

[rick-de-water]

@TahirAhmadov You can say such things about pretty much any syntactic sugar. At least this one makes the language more consistent.

[rick-de-water]

Running into this myself as well. It feels odd that this can be done with record but not with any of the other object types (interface/class/struct). I don't think record should be an exception, and it should be made consistent instead.

// What I have to write
public interface IFramebuffer : IDeviceObject, IDescribedObject<FramebufferDescription>, IDisposable
{
}

// What I want to write
public interface IFramebuffer : IDeviceObject, IDescribedObject<FramebufferDescription>, IDisposable;

[CyrusNajmabadi]

Note that this directly conflicts with the proposals people have raised where they want type decls to work like namespaces (where you can use semicolon, but the scope is extendedto the end of the file.

[TahirAhmadov]

@alfasgd - consistency isn't a goal. There are programming languages that enshrined consistency more than anything else that are perfectly unusable - and now forgotten to history. We studied a few (for other reasons) back in my university days, long, long ago.

I would disagree with this. While "consistency" is not a clearly defined quality - you have to choose what is consistent with what, and that is a point of debate - it very much is a goal, not just of language design, but of any software (or even hardware) endeavor. I'm not sure what languages you are referring to, but there may have been a million reasons for their failure. I highly doubt "consistency" was anywhere near the top of the list of those reasons.

[theunrepentantgeek]

Let me be more clear.

Consistency in and of itself has precisely zero value.
Consistency has value only to the extent that it reduces the number of different concepts, the amount of learning required.

Consistency is a good thing when it helps developers get their job done because things work the way they expect without having to reference manuals, read other documentation, ask a friend, or do a web search. When this happens, consistency saves time and improves productivity.

Consistency is a bad thing when it adds seldom used edge cases that developers don't expect because they're seldom seen and surprising when encountered. When this happens, consistency creates pitfalls and costs considerable time.

Those languages that I remember studying were unusable precisely because their rigid consistency made writing - and reading - the code difficult. Instead of simplifying things, the enforced consistency placed a higher cognitive load on the developer.

Forcing foolish consistency on C# would be ignoring the lessons we can learn from those older languages.

Good language design - as we've seen over the history of C# - involves achieving careful balance between consistency that creates predictability & productivity, and consistency that creates pitfalls and problems.

[TahirAhmadov]

@theunrepentantgeek that I 100% agree with - like I wrote, deciding which concepts should be consistent with each other is important, and is (or at least should be) a big part of the design process. Obviously, we don't want to make everything consistent just for the ideology.

[Rekkonnect]

When there are conflicts in the syntactical choice between two concepts, you choose the healthiest and most applicable option. In this case, file-scoped type declaration is more applicable, but its healthiness is controversial. On the other hand, it's healthy to support the feature like it is on records, but not nearly as applicable, without being almost completely unapplicable. At least half the existing projects would benefit from that, unlike other rarely used features.

We have learned lessons, we have seen why languages fail. The problem wasn't exactly enforcing the consistency, but rather playing on the same broken field and applying patches on top of patches instead of redoing the whole concept, or starting a brand new language from scratch. This specific consistency proposal will definitely not render C# unusable by any means.

[CyrusNajmabadi]

the healthiest and most applicable option.

Agreed. That would be following namespaces. It makes things the most broadly applicable and brings the most benefit to users. Adding this syntactic feature for the 1:1000 case around be an enormous waste of an syntactic option.

[davidkarlsson]

Am I crazy or has this language feature now been implemented in C# 12 both for classes and interfaces? I'm testing this with .NET 8 RC2 and I can now omit the curly brackets for these types when they have an empty body.

What is strange though is that I can't seem to find any more information about it either here on in the Roslyn repo but there's even a new Resharper rule for it called resharper_redundant_type_declaration_body_highlighting so I guess it must be true? Why is it so hard to find any more information about this if this is the case? Shouldn't it be listed here as a new language feature in C# 12?: https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md#c-120

[ufcpp]

It is part of the primary constructor for non-records.

csharplang/proposals/csharp-12.0/primary-constructors.md

Line 39 in 27bd72a

Class and struct declarations are augmented to allow a parameter list on the type name, an argument list on the base class, and a body consisting of just a `;`:

[davidkarlsson]

@ufcpp Oh I see! I didn't think this had anything to do with primary constructors so I didn't check there. Thanks for letting me know.

[KennethHoff]

I believe you can do this for anything now - including enums if you feel like it.