Should the console project template use top-level statements

[tdykstra]

For .NET 6, the console project template was changed to use top-level statements. The code that is created in Program.cs is:

// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");

In earlier versions of .NET and .NET Core, the code that is created in Program.cs is:

using System;
using System.Collections.Generic;
using System.Linq;

namespace MyApp // Note: actual namespace depends on the project name.
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Discussion about whether this was a good change began in https://github.com/dotnet/docs/issues/26313 but there was some confusion about what exactly the various up or down votes applied to. This issue provides comments to vote on that clearly describe the options.

[abecasism]

I share a list of things about why I want the old template back, or at least as default. I don't have anything against the feature.

• I'm don't like hidden magical variables. Yes, I mean the arguments of Main.
• I don't like implicit usings added by the compiler. I know I can turn it off, but I think it should be off by default.
• I can't add other methods, fields, or properties to Program without recreating the old template manually. Well, I can add methods but it gets mixed with Main code, like C# is becoming a scripting language.
• Aditional usings gets mixed with the code and you don't know if they are declared inside the namespace or outside.

Maybe, If Main was visible, it would look like C, which is a little nicer to see that .NET 6 template as it is.

[rajesh5sep-code]

1. I at least would like to see the Main method with the parameters passed to tell me that I am in the Main method .
2. The use of implicit usings should be a class file in the project where I could see it. This are just my thoughts

[AndrewH2O]

While I like the direction .net is going this change gets my down votes as it raises too many questions for minimal or no gain. I am now wasting energy thinking about that which was a known quantity before, taking away time from more exciting things. 1) Under the traditional project layout you can fold the usings away in a collapsible region if tidiness worries you so I don't see the benefit here. 2) What about conflict resolution? If I find the wrong using is being used, how do I discover this? Don't want to run the program only to experience odd behaviour. 3) The program.cs again requires thinking, what about return statements?. Odd mixture of braces for methods whereas the top level has none so it becomes confusing to understand scope. 4) The usings were also useful when learning the framework as you could easily reach for documentation at a glance. 5) Not keen on magic. 6) Implicit derivation of most things is bad, look for example at the confusion in javascript where stuff is implicitly done. I would rather have a little bit more verbosity in the name of explicitness.

[IanKemp]

I don't understand why something as stupidly unnecessary as this was not only prioritised, but actually implemented, when there are so many other VS and C# language features that actually add value, yet remain unimplemented. Seems like the MBAs are taking over at Microsoft... whatever happened to "all features start at -100 points"?

[enkeyz]

I don't understand why something as stupidly unnecessary as this was not only prioritised, but actually implemented, when there are so many other VS and C# language features that actually add value, yet remain unimplemented. Seems like the MBAs are taking over at Microsoft... whatever happened to "all features start at -100 points"?

Yeah, I wondered too how this actually got into release, when nobody asked. Strange. Microsoft could've realized by now, if they want to do proper open-source, they shouldn't cut any corners.

No wonder why most devs prefer not to work with Microsoft tools...

[mwwhited]

Since they've gone open source "cool" has been wining over useful. I was happier when language and framework were separated as it was easier to upgrade projects. Now we have to screw with multi-targeting because The latest bits for EF Core and other framework components have constant undocumented breaking changes and are tightly coupled to abstract/contract versions... so much for ".Net Standard"

They even broke their in-house JSON serializer when releasing .Net 5.0 by blindly adding null check logic places where nulls were safe before.

Who needs backwards compatibility and well documented upgrade paths when you can just toss and rewrite every 12 to 24 months.

[AFract]

The only thing I like is the ability to declare the namespace at top of code as a single instruction, to avoid to have to nest everything else inside of it. But I want to get back my old Program class / Main method clearly readable and accessible, I don't see the point of removing it, apart for quick prototyping or testing of very short programs, but there is already a lot of good tools around to do this.

[xxxxue]

Before c# was my favorite language . Since the upgrade Net6, I'm a little disgusted with c# . Because every time I create a new project, I have to manually complete the namespace and main functions .

[died]

Before c# was my favorite language . Since the upgrade Net6, I'm a little disgusted with c# . Because every time I create a new project, I have to manually complete the namespace and main functions .

Maybe they just want people quit C# so they make stupid change.

[DefinitelyADev]

Maybe they just want people quit C# so they make stupid change.

@died If that's all it takes to quit a language is this, then you are going to quit every language, because no language is perfect. It is a change that some audiences like and some don't, what would be nice and relatively easy for MS, would be to include a damn dropdown or bullet choice and let the user choose what he/she wants. As for me, I have created a template as I want it, for now, though I would like to have the damn option! For now, all I see is that MS is ignoring the issue and that's more aggravating than the change.

[mwwhited]

@DefinitelyADev why so reasonable :P ... this is my issue with this as well. Why not have both templates versus everyone to have the one that requires the most effort to fix.

[GalaxyNetworks]

https://dotnet.microsoft.com/download/dotnet/1.1 is the .NET 1.1 SDK. Download that and you can create the ASP.NET Core 1.1 templates with VS 2022.

If you have complicated startup logic, you might want to keep using startup. But with complicated startup logic, the templates aren't much help.

I usually likes Microsofts interactions with the community, but I must say I really dislike comments arguing that you can just use templates from an old SDK. Sure you can use old templates, but you'd then need to target that old SDK and then retarget to the new one. That's not useful at all! And why should one have an old unsupported SDK just because Microsoft made a bad choice with top-level statements. Based on all these comments it seems like the ASP.NET Core team just doesn't care how the community feels about the new templates.

It's important to remember that we can create our own templates. VS 2022 with .NET 6 is however the very first time I've ever felt the need to replace the default templates.

I can see a use case for top-level statements with very short Azure Functions that could work like a single method. However, as soon as you make a project with multiple .cs files, it just seems completely out of place. You have one single file with top-level statements and then you're back at regular .cs files. Why? What does it really give you? What benefits do you get by shaving off a few lines on what would be the new entry point .cs file?

It seems like someone thought they got a good idea and now you're fully committed to a niche feature. Yes! I can see use cases for top-level statements, but they are rare! To me Azure Functions would make sense with top-level statements, but not a console project or any other larger project.

[iamkrillin]

I'm going to go ahead and take time out of my day and complain about how dumb this change is. if your going to insist on this nonsense you need to at least add a QUICK way to add the previous template code back.

[mwwhited]

I'm going to go ahead and take time out of my day and complain about how dumb this change is. if your going to insist on this nonsense you need to at least add a QUICK way to add the previous template code back.

I totally appreciate your comment. From the changes. I've seen for the last few years they have been active chasing stuff that demos well and works well for simple projects. Since going to .Net Core Microsoft has seemed to forgot the large project and enterprise developers that have been their bread and butter for decades.

Sure, make this a new template or even an option on all templates but for those of us that do real work and not just demos changes like this add tons of time to our do... and when we get stupid "fixes" such as "just use the old framework then upgrade" we just get really annoyed. If it's as simple as a template create it as a new one. Heck, the hoops you have to jump though to create a azure function project that supports IOC and components reuse is a pain. Not everyone wants the bloated, copy/paste, code by stack-overflow approach the new regime seems to be heading towards. Some of us want to actually get work done, have at least a path to follow if there are going to be breaking changes... and not have to spend extra time restoring entry point code when we want to get work done.

[cho7052002]

just wonder, which type should be default template? I'll pick previous, cuz there are so many references using previous template. someone who is new to C# would be confused with new template.

[ahwm]

I’d say the votes and the comments give a pretty clear indication. Almost 400 votes combined to remove the top level statements from the default template or add the option to switch. Contrast that with 17 in favor of leaving it as is.

[bravecobra]

I’d say the votes and the comments give a pretty clear indication. Almost 400 votes combined to remove the top level statements from the default template or add the option to switch. Contrast that with 17 in favor of leaving it as is.

And we have yet to hear from the people of Microsoft. There is no real conversation with them going on. I sometimes even wonder whether they are watching this issue. Are we at any point really persuading them to take action? Please MS, talk to us!

[sergeytunnik]

Having a choice is what everyone expectes from changes being those radical.

[StingyJack]

@Rick-Anderson @tdykstra - if I just want to add a function (other than Main) to the program.cs file, this change does not leave me with very productive choices. Either I redo as net5 and jiggle project properties, I copy the net5 template contents into my program file, or I hand write all of that which was previously created automatically.

Its fine to show off something neat, but not when it comes at the expense of our productivity.

[tpressley]

@Rick-Anderson @tdykstra - if I just want to add a function (other than Main) to the program.cs file, this change does not leave me with very productive choices. Either I redo as net5 and jiggle project properties, I copy the net5 template contents into my program file, or I hand write all of that which was previously created automatically.

Its fine to show off something neat, but not when it comes at the expense of our productivity.

After playing around, I discovered that you can just do something like:

Int MyMethod(int arg) { ... }.

The key is you cant use an access modifier. It's completely counter intuitive, and MS did not explain this at all, and obviously if you actually want access modifiers you have to do what you described.

[mwwhited]

@Rick-Anderson @tdykstra - if I just want to add a function (other than Main) to the program.cs file, this change does not leave me with very productive choices. Either I redo as net5 and jiggle project properties, I copy the net5 template contents into my program file, or I hand write all of that which was previously created automatically.

Its fine to show off something neat, but not when it comes at the expense of our productivity.

After playing around, I discovered that you can just do something like:

Int MyMethod(int arg) { ... }.

The key is you cant use an access modifier. It's completely counter intuitive, and MS did not explain this at all, and obviously if you actually want access modifiers you have to do what you described.

That's because you wrote a local function and not a class method. It looks correct for what you wanted but it's scope only lives in that top level method.

[tpressley]

@Rick-Anderson @tdykstra - if I just want to add a function (other than Main) to the program.cs file, this change does not leave me with very productive choices. Either I redo as net5 and jiggle project properties, I copy the net5 template contents into my program file, or I hand write all of that which was previously created automatically.

Its fine to show off something neat, but not when it comes at the expense of our productivity.

After playing around, I discovered that you can just do something like: Int MyMethod(int arg) { ... }. The key is you cant use an access modifier. It's completely counter intuitive, and MS did not explain this at all, and obviously if you actually want access modifiers you have to do what you described.

That's because you wrote a local function and not a class method. It looks correct for what you wanted but it's scope only lives in that top level method.

That makes sense but it's an even further example of just how dumb this change is. I've been working with .NET for 10 years, and I didn't even understand how a basic 2 function CLI program was actually structured as a result of this change, because it abstracts literally the entire file.

[StingyJack]

After playing around, I discovered that you can just do something like:

If I need a quick and dirty c# script I am going to use roslynpad, linqpad, or many other things before firing up visual studio and waiting for it to load up.

[tpressley]

After playing around, I discovered that you can just do something like:

If I need a quick and dirty c# script I am going to use roslynpad, linqpad, or many other things before firing up visual studio and waiting for it to load up.

That's nice, but there's industries where the effort required to get these less common tools is very high compared to the amount of time they actually save you.

[AndrewH2O]

@tdykstra Thanks for setting up this issue. In the msdn docs there is this Tutorial: Explore ideas using top-level statements to build code as you learn which states: "Top-level statements simplify programs that are based on console applications. These include Azure functions, GitHub actions, and other small utilities. For more information, see Top-level statements (C# Programming Guide)."

As a suggestion if we have the old console project template back and re-badge the top level statements version as console app for cloud, then we get a choice and it conveys the intention behind the change.

[zzti]

It’s a terrible and confused change in dotnet, please ‘git reset —hard’!

[StingyJack]

That's nice, but there's industries where the effort required to get these less common tools is very high compared to the amount of time they actually save you

@tpressley - Ive been there and feel for you, but I've found that's actually a per company problem and not an industry problem, even in heavily regulated industries like pharma and general finserv. Alot of them have approved application lists with tools like this on them. Even if the program isn't on the list, you can write a csharp script runner for yourself to use in an hour or less in VS.

[zzti]

“Top-level statements” should only be used for script-type language! Yes, that’s a good idea to create a new script-type template to suite this situation.

[lscorcia]

Just wanted to mention that my junior devs are incredibly confused by this change.

[AFract]

Just wanted to mention that my junior devs are incredibly confused by this change.

Interesting for a feature supposed to make things easier to understand and to use ;)

[AFract]

“Top-level statements” should only be used for script-type language! Yes, that’s a good idea to create a new script-type template to suite this situation.

Even for scripts I don't like them and I can't find any single reason to widely adopt them.

Implicit namespaces and "file scoped namespaces" are great feature to reduce code nesting and overhead code, I would also be able to understand to remove the "Program" class declaration, but Main method and other methods and declarations contained in Program class are mandatory for me for any real program.

[GalaxyNetworks]

Implicit namespaces and "file scoped namespaces" are great feature to reduce code nesting and overhead code...

Assuming we're talking implicit using I find them magic and a code smell. You'll no longer have a clear overview over the dependencies a class actually depends on. You just assume that a class always uses or are allowed to use the same global namespaces.

File-scoped namespaces I can understand. I very rarely have more than one Type in a namespace and I've never needed two namespaces in a single file. That's a code smell too.

I would also be able to understand to remove the "Program" class declaration...

NO! You either make it script-like or you do nothing! The class declaration is the important part!

If Main and other potential methods or declarations in the Program class are mandatory for you, then you should also want to clearly define the Program class. Why are these important for you? Will you be calling them from other classes?

Ignoring how horrible top-level statements are for a language like C#, it still allows you to define methods, or rather local functions. Consider this code, based on the new console template with top-level statements:

using System;

ConsoleWrite( "Hello, World!" );

while ( true )
{
  var input = ConsoleRead( "Echo this" ); // var is implicit magic that I'm okay with.
  ConsoleWrite( $"You wrote: {input + Environment.NewLine}" );
}

void ConsoleWrite( string message )
{
  Console.WriteLine( $" {message}" );
}

string ConsoleRead( string message )
{
  Console.Write( $" {( string.IsNullOrWhiteSpace( message ) ? "#" : message )} > " );
  return Console.ReadLine();
}

That top-level statements code is roughly the same as this regular code:

namespace I.Hate.TopLevelStatements;
using System;

public class Program
{
  public static void Main( string[] args )
  {
    // The actual code of your new top-level statements 'program.cs' file starts here!
    // I assume magic reads the using statements and defines them outside the class.
    ConsoleWrite( "Hello, World!" );

    while ( true )
    {
      var input = ConsoleRead( "Echo this" );
      ConsoleWrite( $"You wrote: {input + Environment.NewLine}" );
    }

    void ConsoleWrite( string message )
    {
      Console.WriteLine( $" {message}" );
    }

    string ConsoleRead( string message )
    {
      Console.Write( $" {( string.IsNullOrWhiteSpace( message ) ? "#" : message )} > " );
      return Console.ReadLine();
    }    ​
   ​// Your new top-level statements 'program.cs' file ends here!
  ​}
}

"Everything" you write in a top-level statements, Program.cs file, is simply local to the old Main method. You even have access to 'args'! Program is a class like any other class, therefore you should still declare it as such.

If top-level statements are the new big thing, then why not infer the class name from the file name and get rid of all definitions, class, interface, enum and such... Be gone! Let the magic do everything.

I seriously fail to see how explicit definitions are bad. I'd argue that explicit code, even with repetition, is much better than implicit magic doing insane stuff behind your back.

There's a fine balance between how much implicit magic a language really should have. And there's a time and place for everything.

For tiny script-like programs that only uses external libraries and doesn't have any classes of its own. Yeah, sure! Top level statements would be simple and neat.

As soon as you add your own class to the project, it all goes to hell!

If you need classes for a top-level statements project, then they should be defined as local to main as well:

var consoleHelper = new ConsoleHelper();

consoleHelper.ConsoleWrite( "Hello, World!" );

while ( true )
{
  var input = consoleHelper.ConsoleRead( "Echo this" );
  consoleHelper.ConsoleWrite( $"You wrote: {input + Environment.NewLine}" );
}

class ConsoleHelper
{
  public void ConsoleWrite( string message )
  {
    Console.WriteLine( $" {message}" );
  }

  public string ConsoleRead( string message )
  {
    Console.Write( $" {( string.IsNullOrWhiteSpace( message ) ? "#" : message )} > " );
    return Console.ReadLine();
  }
}

[rolerik]

I would prefer to have two different templates. Console App: same as the .NET 5 template, except changing to namespace declaration instead of namespace block. New template, for example "Script App", with top level statements as in the .NET 6 template.

[zvrba]

Yes, annoying change and a setback in usability for anything more complex than a single-file program.

[mwwhited]

25 for, 300+ against, another 300+ for both. Is anyone at Microsoft paying attention? That's over 24 times as many people wanting the templates restored with half being okay to have an option for both. Could we at least get an acknowledgment that you are even looking into this?

[ahwm]

25 for, 300+ against, another 300+ for both. Is anyone at Microsoft paying attention? That's over 24 times as many people wanting the templates restored with half being okay to have an option for both. Could we at least get an acknowledgment that you are even looking into this?

Apparently they're not going to change anything for .NET 6 and any changes to the template will be in .NET 7 (!). So that means we have to

1, Wait for .NET 7 to come around, and

2. Potentially target .NET 7 and re-target to .NET 6 as we do now if we want to target the LTS version ?

[jannikbot]

Very out of tune change, The only thing this adds for beginners is an additional layer of complexity.

[myFirstway]

It's too bad!!!

[nft-legends]

This feels like just one more attempt to remove buttons / icons and hide functionality. STOP doing that!! Like every UI over the last 20 years. We're developers, we are perfectly fine with a bunch of buttons and code! I want to see all the code regardless of how complex it is. I don't want crazy "magic" going on behind the scenes.

I realize, change is hard, but this is a bit much..

[EvaldasPovilaitis]

The new templates, top level statements, file scoped namespaces, global using directives, default interfaces, implicit usings are harming the language, community, new comers and leans towards degeneration of the language. The language has been harmed by these changes, not improved!

I value everyone’s hard work on improving our programming language, just please try to not to ruin what makes it better for us than other languages!

My reasoning: Since I have first time seen C# in around 2011, I was fascinated about the elegance and design of the language. After C++ and Java, it simply looked more expressive, more well organized, simpler but yet as powerful as it gets. That’s why I have always had a lot of trust and respect for people working on the language. I felt that our mindsets were aligned.

Unfortunately, my trust and respect started to tremble with features introduced in C# 7 and later. I started to ask myself what’s the point of these changes.

• C# 7.0
  • Ref return values and ref locals (C# Guide)
• C# 7.2
  • Reassign ref local variables.
  • Declare read-only struct types, to indicate that a struct is immutable and should be passed as an in parameter to its member methods.
  • Use the ref read-only modifier on method returns, to indicate that a method returns its value by reference but doesn't allow writes to that object.
  • Declare ref struct types, to indicate that a struct type accesses managed memory directly and must always be stack allocated.
  • The private protected access modifier enables access for derived classes in the same assembly.
• C# 8
  • Readonly members
  • Default interface methods
  • Using declarations
  • Disposable ref structs
• C# 9
  • Records
  • Top-level statements
• C# 10
  • Record structs
  • global using directives
  • File-scoped namespace declaration
  • Record types can seal ToString()

Some, I understand are for performance improvements and writing highly efficient/performant code. But then how to explain these:

• Default interface methods – What’s the difference between interface and an abstract class? Doesn’t this severely hurt language purity and design? Whenever I told someone about this, they were shocked and confused. Also, the documentation has very poor reasoning why this feature was added in the first place. It’s not convincing enough. We could just have used abstract classes or designed more carefully and that's it.
• Records – one more first-class citizen and for what? Made to be immutable but can also be mutable? We had class, abstract class, interface, struct and now in addition record (record struct, readonly record struct, record class, abstract record class). For anyone new or using this language for a while it’s an overhead to learn all of them just to understand what and when is appropriate to use especially how blurry is records added value. I don’t have anything against class, abstract class, interface, struct as they have very clear reason to exist.
• Top-level statements, implicit/global usings – C# is object-oriented language at its core. Every definition has a clear structural hierarchy: assembly -> namespace -> class/struct/interface/delegate -> fields/constructor-destructor/properties/methods. It’s a must to know and understand this. This what makes the language simple and easy to reason about. So, the effort spent and explanations around why this feature is useful are illogical at best. If we as C# practitioners would like magic, strange and unintuitive behavior we would simply use JavaScript. I don’t want something like this for C#, Javascript WTF | A site where we can all share in those little WTF moments we enjoy with Javascript.
• File scoped namespaces – for what? To get rid few spaces, two curly braces and make the hierarchical structure of C# code less visible (these days we use 49inch monitors so any complains about horizontal space are quite strange)? This is harmful to the language and to the community we try to build.

[zvrba]

@EvaldasPovilaitis many of the additions in your list are actually good additions. Many of the features quoted (ref...) is for performance reasons. Recently I've experimented with writing high-perf code in C# and the generated assembly was what a C++ compiler would generate. So there's that. You can't say these are unnecessary changes.

I'm indifferent to default interface implementations (Java has them, they're widely used there w/o any controversy, and as I understand, there'll be Java interop at some later stage). "Make a better design" is easier said than done, nobody has a crystal ball to foresee the future.

I don't "get" records. In places where they could be useful (caching records from a database), you can't use them (EFCore doesn't support records).

Also, of the other new features, nullable reference types are botched. I just turn them off project-wide.

On the other hand, I welcome file-scoped namespaces and using-declarations. Less indentation and braces = neater code.

But top-level statement, global usings... it's junk. Having experimented recently with Blazor, I can see how these can simplify writing pages, but this should not have been the default for all new project templates!!!!!

[SittenSpynne]

This was a very, very bad choice. If you watch the /r/csharp subreddit, there are usually about 2-3 posts per day from newbies who just paid for a C# course and are completely lost because the tutorial's not updated and they have no clue why they can't get Visual Studio to do what the video does. Here's today's first. It's not like a newbie automatically knows, "Oh I should search for "top-level statements" to learn how to handle this". I don't think 20 years of videos and tutorial articles are going to be rewritten or replaced in a hurry.

A better solution would have been to create this as a secondary set of templates so people can choose whichever template style they want. These are neat features and good for certain kinds of projects, but it's causing a lot of confusion that you've broken the first thing newbies see.

[MD-KpRk]

Top-level statements is sugar. It`s too bad

[CyrusNajmabadi]

@EvaldasPovilaitis To address points like this:

Unfortunately, my trust and respect started to tremble with features introduced in C# 7 and later. I started to ask myself what’s the point of these changes.

As an example:

File scoped namespaces – for what? To get rid few spaces, two curly braces and make the hierarchical structure of C# code less visible (these days we use 49inch monitors so any complains about horizontal space are quite strange)? This is harmful to the language and to the community we try to build.

First, i did this lang feature :). And, to give you an idea,this was one of hte most massively upvoted and popular lang proposals in our history. It received huge amounts of support across practically every part of the ecosystem and community. Since release, it's gotten overwhelming positive support with near unanimity of feedback that is greatly cleans up code in nearly every file of a repo.

You may not feel like it's valuable, or that your personal coding rig is the same as everyone else's. However, to the rest of hte community the feeling is quite different. This is the way with all lang changes where if you're in the group that cares, it's a great win, and if you're in the group that doesn't, you just feel like that effort was wasted.

As to the rest of your points:

Default interface methods – What’s the difference between interface and an abstract class?

An abstract class can have state. DIMs cannot. DIMs can have multiple inheritance, abstract classes cannot.

Doesn’t this severely hurt language purity and design?

I don't see why. Why does language purity mandate that a default impl of an interface method cannot be present?

We could just have used abstract classes or designed more carefully and that's it.

You're missing the point of DIM. This is for cases where an interface was already chosen and now the owner of that interface wants to change it. That could never be done in the past due to breaking cahnges. Now it can. Saying "use an abstract class" isn't viable because hte interface is already there. Saying "design more carefully" doesn't help because no one can plan an interface to be perfect for decades in the future.

Records – one more first-class citizen and for what?

To provide much more desirable semantics for values, with far less effort than what is necessary in C# today.

For anyone new or using this language for a while it’s an overhead to learn all of them just to understand what and when is appropriate to use especially how blurry is records added value.

And, at the same time, it's massive overhead today to try to write a value. Literally dozens and dozens of lines of code to express a basic concept where one line can do.

Top-level statements, implicit/global usings

Covered elsewhere, but this is also a bunch of stuff that everyone is force to care about, which often they do not need to care about. So this streamlines things majorly for tons of users and tons of programs.

[StingyJack]

@CyrusNajmabadi as good of a response as that was, most of us in this issue are here about the jacked up console project template. Can you speak to that or is it outside of your AOR?

[CyrusNajmabadi]

I like the new template. Most new console apps I make don't need the ceremony and cruft of either a class declaration or main method.

[EvaldasPovilaitis]

@zvrba, @CyrusNajmabadi thank you both for sharing your views.

The main point of my initial comment was to say that I find the new templates particularly bad and just breaking what used to work fine plus adding a lot of chaos in the community. Also, pointing out that IMHO the new language features used by the new templates (top level statements, implicit usings) and few others (global usings, default interface methods, records) are very questionable and even harmful to the language. I have expanded in my initial comment to provide more context regarding the way I view things.

Now about the templates. Few clear signs that things went sideways (Usually bad decision in coding is followed by a chain of bad decisions. I guess it applies here also):

• Since when do we leave comments in templates with link to explain the template which is supposedly single super simple golden line?

  // See https://aka.ms/new-console-template for more information
  Console.WriteLine("Hello, World!");

  • Also, since when professionals have to be impacted by features created for noobs. To use proper template, I am recommended by docs to create .NET 5 project and then later on retarget .NET 6. When I have seen this, I was speechless. How did this seem acceptable to anyone on the .NET product team? Does anyone care for people using this language currently or just new comers? Because these new templates have been advertised as simpler starting ground for people new to C# (Do we have more people joining every year, or more working professionally overall?).

Let’s investigate why these templates are so bad in my opinion (More than happy to be proven wrong!).

C# at its core – fundamental code organization:

namespace YourNamespace
{
    using System;

    internal static class Program
    {
        private static void Main()
        {
            Console.WriteLine("Hello world!");
        }
    }

    public class YourClass
    {
    }

    internal struct YourStruct
    {
    }

    public interface IYourInterface
    {
    }

    internal delegate int YourDelegate();

    public enum YourEnum
    {
    }

    namespace YourNestedNamespace
    {
        public struct YourStruct
        {
        }
    }
}

Due to top level statements even this sample is now messed up in the documentation.

Every type is declared in some name space or is nested in another type. Every method/function is declared on some type. Whenever types in other name spaces than our type need to be accessed, we access them by importing types in those name spaces with using statements or by typing the name space plus the type name everywhere it is used in the current scope. Curly braces are the fundamental indicators of scopes. These are the fundamental traits of C#.

What do the new templates, top level statements, implicit usings attempt to do? Hide the fundamental traits of C# pretending that’s boilerplate! Am I the only one to whom that feels insane?

Another one, since when did we forget or stopped caring at all about Single Responsibility/Separation of Concerns and started promoting people writing everything in a single file, in a single hidden method at Program.cs. This also applies to ASP.NET Core templates (Minimal APIs is a totally different topic ☹).

Last, @CyrusNajmabadi , I hope you understand now the way I view removal of curly braces for namespaces to introduce the file scoped namespaces - crippling the language. The upvotes you were talking about most likely never have been put by pro’s ☹ or people understanding the language concepts to reason about them because they were already happy the way it was.

Another one, @CyrusNajmabadi , Default Interface Methods. C# interface used to be a contract without carrying any implementation whatsoever. Most of the other languages didn’t have such a pure expression of contracts. Unfortunately, nor C# anymore!

I have read the docs, tried reason why one or another feature was added but as I said I see shift in the language team’s mindset towards something unclear ☹ or maybe that are people new to the language with their feature requests, or maybe even worst an attempt to make C# similar to other less polished languages ☹.

[CyrusNajmabadi]

are very questionable and even harmful to the language

Thanks for sharing your feedback on this. However, know that thsi is likely an impasse for us. We did these features because we felt they were very beneficial and quite good for the language. If we hadn't felt that way, we wouldn't have done it.

So I totally get that it's not something you would have preferred. However, the decision making flows from that belief (which definitely has not changed since the feature was actively tested by many and has since launched.

[CyrusNajmabadi]

Since when do we leave comments in templates with link to explain the template which is supposedly single super simple golden line?

There are commonly transitionary periods. In many circumstances we've left comments to help people understand that there has been a change (normally simplifying) and as such they don't need to do things they might have previously thought necessary.

[CyrusNajmabadi]

Since when do we leave comments in templates with link to explain the template which is supposedly single super simple golden line?

Ignoring the pejorative, this feature was made for all developers. An active reason we did this was due to lots of feedback industry-wide from professionals that they disliked all the extra ceremony they had to add when in C# that seemed to add no value. This sentiment was given by tons of first, second and third party sources. During the development process this was also one of the most popular changes we made, with a tremendous amount of positivity around reducing general clutter and ceremony that many felt that were constantly forced into.