Move `ImplicitUsings` and `Nullable` into the core targets

[timheuer]

In every one of our templates since .NET 6 we have now defaulted to include the ImplicitUsings and Nullable settings as opted-in:

<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>

This now feels like unnecessary boilerplate code for the modern frameworks and getting toward less verbose settings and more toward opinionated views of the platform/SDK defaults. The time feels right now for .NET 10 to move these settings into the default targets and remove from project templates. When you look at new flows as well as people approach C#, these additional settings -- which we default opt them into -- become learning stumbling blocks of why they are there if they are preferred for greenfield/new situations. In our single-file run capabilities in .NET 10 for example, you move from a single simple .cs file and with dotnet project convert you get the expected csproj file, but now new properties that you have no idea where they were before, why you now have to know about them when you didn't before, etc.

These should now be the default path forward for modern C# development.

Impact Concerns

This likely will cause WarningsAsErrors impact as without TFM-targeted changes this would be an upgrade breaking change, but only in new scenarios. Existing properties set would/should be honored still with the local csproj setting overriding the target. Someone who simply removed the property rather than set it do disabled for an example would now be more impacted.

Ideally if a if (TFM>=net10.0) could be applied in the targets this would help mitigate, but not help with cleaning the template experiences removing boilerplate.

[TheBuzzSaw]

Not on board with ImplicitUsings. I turn it off in every new project. I simply do not have namespaces that I want included in every single file, and I do not want names suddenly colliding in non-obvious ways.

This is not "unnecessary boilerplate". It's one property in a project file that makes a fairly important decision. I think having to explicitly turn it on (as it currently works) is the best way to do it, and we should just keep it that way.

[londospark]

I agree with @TheBuzzSaw for many of the same reasons. I feel like knowing where types are coming from is very useful and that having ImplicitUsings turned on is a recipe for bugs with very little benefit. A good IDE will add usings for you, so you don't even need to do it yourself. I would go even further and suggest that it was a mistake to make that the default at all.

[Frulfump]

I agree with @TheBuzzSaw and @londospark. I always set ImplicitUsings to disable and my reasoning is the same. I don't want all of those namespaces to be available in all files I edit. I always look at the usings added when reviewing new code and have caught a few issues by that when the wrong/(unexpected) namespace is referenced. It's very annoying that some templates have it added as enabled by default like the xUnit/Console/WebAPI templates, so maybe it's worth to instead discuss their removal in templates as well. Based on experience when Implicit usings are added developers start using GlobalUsings.cs to add even more namespaces as they grow afraid of having namespaces in the .cs-files themselves and the issue explained above becomes even worse instead.

As @londospark said, knowing where types comes from (or can come from) is important and all the major IDEs make it trivial to add missing namespaces.

We always have intellisense in the IDE but sometimes when you look at code you are not in an IDE like GitHub/Azure DevOps PR review.

For Nullable I always set it to enable as I want warnings during design/build time that would otherwise happen during runtime and I consider the nullability of types to be an important design decision. It's a really nice feature and it's been out there for quite some time (.NET Core 3.0 / C#8 in September 2019) so the ecosystem has adopted it now in large parts. Most .NET code but not all dotnet/runtime#41720 and some first party code example Azure/azure-sdk-for-net#33004 (comment) (old comment so maybe things have changed) that still needs to be updated but a majority is there today and some third party that needs to be updated but it's less and less common to see annotations missing.

For beginners(or developers with 10+ years of experience for that matter) when they explicitly set Nullable to enabled there's a risk that they are led to believe that a NullReferenceException (NRE) can now never happen. Annotations can be incorrect and they don't actually stop a null during runtime even if the annotation is correct. A beginner would be blissfully unaware of the implications of Nullable if it's implicit so that's an upside I guess...

Furthermore it's trivial to add and most templates have it already, it's easy to add to your Directory.Build.props to have it apply to all your projects and that's what I usually do. The push from Microsoft to remove everything from the csproj and "simplify" things actually makes it harder for beginners to start learning about different concepts, if I see a setting in a file I would search for its implications, if it's just automagically enabled I wouldn't even know it existed and miss out on an opportunity to learn. Same with the Console template, it was easier to start developing when it actually contained code and not the now super simplified top-level stuff as the grow up story is more complicated for a beginner.

I don't like Microsoft's attempts at dumbing things down and hiding important aspects though with the motivation that it's for beginners, I think some times you are doing beginners a disservice by hiding some things.

Maybe Microsoft can find other ways to further encourage the use of Nullable enable in an informed manner.

Maybe it should have been one issue per setting as they merit their own discussions?

[DamianEdwards]

For folks that are already disabling things like ImplicitUsings in new projects, this proposal doesn't change much. You still have to change something in new projects but now you need to have the line that turns the property off rather than just deleting it.

[KalleOlaviNiemitalo]

Such a change would be a bit more palatable if there were a simple way to add <ImplicitUsings>disable</ImplicitUsings> and all the necessary per-file using directives when creating a project from a template.

Possible user experiences:

• Run first dotnet new, then dotnet format explicit-usings.
• Run dotnet new --explicit-usings, which would be implemented in each template.
• Specify defaults for dotnet new template options in per-user and per-directory configuration files so that --explicit-usings need not be typed every time. This might have to display a reminder each time those settings take effect, in case the user is following some tutorial and wondering why the result differs from what was documented.

[TheBuzzSaw]

For folks that are already disabling things like ImplicitUsings in new projects, this proposal doesn't change much. You still have to change something in new projects but now you need to have the line that turns the property off rather than just deleting it.

But I still think there is massive value in explicitly stating that things are implicit. Having implicit usings enabled implicitly just creates awkward dark patterns where you now have to know about that setting (and that it's on by default). Meanwhile, in its current form, someone can eventually discover that it's there and know what's going on.

[KalleOlaviNiemitalo]

dotnet/msbuild#12034 is a case of ImplicitUsings causing ambiguity in name lookup; but I suppose the ease of understanding and fixing this ambiguity depends primarily on the content of the compiler error message, less on whether ImplicitUsings is defined in the project file or implicitly enabled by SDK.