Roslyn: Code style to recommend null or 0 literal instead of default literal, when possible

[jcouv]

For simplest cases (built-in types), like string s = default; or int i = default;, a more specific literal makes more sense.

FYI @CyrusNajmabadi

[miloush]

I am not convinced that much, why does it make more sense?

[CyrusNajmabadi]

@jcouv What context are you referring to? You mention "recommend null or 0...", but when are you talking about?

[sharwell]

This is closely related to DotNetAnalyzers/StyleCopAnalyzers#1976 and DotNetAnalyzers/StyleCopAnalyzers#2333.

Currently it only applies to the simplification of default(int) to default. In the future it could also apply to a dedicated code style rule.

[jcouv]

Yes, I'm suggesting a code style that recommends more specific literals, when possible.
If you type string s = default;, a lightbulb would recommend null instead.

[Pilchie]

Tagging @kuhlenh too for backlog prioritization.

[miloush]

@jcouv why is more specific better?

[CyrusNajmabadi]

If you type string s = default;, a lightbulb would recommend null instead.

I'm confused who would type that :)

[jcouv]

@CyrusNajmabadi Another example: void M(string s) {...} that you invoke with M(default). If you think users will already use more specific literal, then no need for code style.

@miloush This would be a style (ie controlled by preference). I think more specific literals make the code more readable. Consider M(default) or M(0), the latter gives you more context/information.

[sharwell]

My main concern here is the ability to expand the feature, i.e. a user-configurable set of "preferred default values". It's much harder to get this right than a simple Boolean option, but I believe the simple option will quickly break down as users want to verify things like CancellationToken.None or enums with a None member.

[CyrusNajmabadi]

Another example: void M(string s) {...} that you invoke with M(default)

My point is this:

What customer does this? null, 0, etc. have been the way to specify defaults since C# 1.0. They're so idiomatic. They're the absolute norm for huge swaths of users. The only user who isn't using this is because they feel like there is specific value in using 'default' (which, for reference types seems... unlikely).

[jcouv]

Makes sense. I'm fine to wait to see if this problem occurs in the wild.

[alrz]

(which, for reference types seems... unlikely).

I would always prefer default for default parameter values and assigning out parameters in failure path.

[CyrusNajmabadi]

Yes. If we were to provide anything here, it would be much more about making it possible for a person to say that they preferred 'default' everywhere, instead of the the more common 'null/etc.'

[jcouv]

Closing as the proposal doesn't seem useful after all. Thanks for the feedback