Templates with <Nullable>enable</Nullable> are very irritating to get started with

[Eilon]

Old AspNet template had a nullable, E I E I O. And on that template he had a reference, E I E I O. With a green squiggle here and a green squiggle there, here a squiggle, there a squiggle, everywhere a squiggle squiggle... you get the idea.

I absolutely love nullable support in C# 10, but in the default template I found it very irritating. When I'm just starting out, I'm not worried about a null value leaking through where it shouldn't, just like I don't add parameter or input validation to every method or API as I write the initial code. But the green squiggles that show up on every other line of code are very distracting. I like squiggle-free code, but not at the cost of having to annotate things before I'm even sure of what code I will end up with.

I'm afraid that having this on by default will be a huge problem for newcomers to .NET who are barely familiar with C#, let alone all the new C# 10 features. And also the multitude of users who are very familiar with C# but don't know the latest C# 10 features or what nullability means. This feature is very in-your-face and it's unlikely to be obvious to a C# 10 newcomer.

I would love a template where the existing code is fully annotated, but without <Nullable>enable</Nullable>. Once I'm in a good spot and I'm trying to clean up code, I will enable <Nullable>enable</Nullable> and go fix the squiggles.

[Bartmax]

just curious, what do you mean by "annotate things" ?

[Eilon]

Explicitly placing various ? and ! as needed to avoid the warnings. Not attribute annotations.

[Eilon]

(I know perfectly well how to do it, I just don't even want to think about it when I'm just playing around in a new project. I certainly will enable nullable once it's a "real" project.)

[Bartmax]

Is there any particular reason why you are not advocating for already anotated teamplates instead of turning it off?
I totally understand your frustration/point, but I believe having Nullable as default will make a bigger impact on what's "standard" and people realizing that having nulls is a bad thing early on will surely helps and maybe there are other options worth evaluating.

[Eilon]

Yeah I figure this has been debated a lot prior to the decision being made to make it the default in the templates.

I logged this bug to add the perspective of a seasoned C# developer who fully knows exactly what these things are, but I still found it annoying in this default experience.

I 100% agree that a "real" project should have nullable enabled and used throughout the project. But when I start out new projects it's usually to test out an idea or play with some other new features.

Here's my crazy idea: The templates have EnableNullableAfter30Days=true enabled. So it's off at first, and after 30 days VS will say "hey, you're still working on this after 30 days??? That's great, would you like to turn on nullable?". Obviously you can enable it earlier if you want, or permanently disable if you really don't care.

[mkArtakMSFT]

@DamianEdwards FYI. Moving this to the Discussions just as a good feedback to consider

[Eilon]

I talked to @Pilchie about this a bit and I think he talked me off the ledge. It might be the case that I am too seasoned and too used to the awfulness of nulls and all the normal workarounds. New devs and old devs alike should just use the annotations and avoid a huge class of bugs from day 1. Time will tell.

[TanvirArjel]

@Eilon I am 200% agree with you. Enabling nullable, implicit global using by default are too much for the new comer to pick.

Most importantly, most of the changes in dotNET 6.0 project templates are rigorous, confusing and over engineering.

So first thing I do after creating a new project in dotNET 6.0 is reverting the over engineerings.

I am really frustrated with the project templates in dotNET 6.0.

[zejji]

I'd definitely argue for leaving nullable enabled, as it really should become the new normal over time.

However, for me, the biggest usability problem is where EF Core models have non-nullable properties, as one currently needs to use = default!; all over the place. However, I think this could be fixed if this C# language proposal for required properties is implemented.

[Atulin]

I'd also argue in favour of NRTs enabled by default, except:

1. Null errors need to be promoted to compilation errors instead of just being warnings
2. The required proposal needs to get through

After those two things are achieved, I'm all for enabling nullability by default. Until then, I have mixed feelings.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!