Obsolete, as of specified version

[kfarmer-msft]

Currently, ObsoleteAttribute can be applied such that it causes a warning or an error. However, in complex and long-lived code bases, teams must take care in tracking APIs marked Obsolete and removing them after a suitable time, generally doing so without help from compilers and tools. In the end, dead code lingers, never gracefully removed as intended.

Given version information in an assembly, the compiler ought to be able to use that in conjunction with Obsolete to provide the following (approximate) prompts to dev teams:

// ObsoleteAttribute(message, major, minor = 0, build = 0, revision = 0)
[Obsolete("Use Method B.", 2)]

• from declaring project version 1.5: warning: Obsolete as of 2.0.0.0. Use Method B.
• from declaring project version 2.0: error: Obsolete as of 2.0.0.0. Use Method B. [At declaration site, include "Remove this API to resolve error." and VS could offer a code fix.]
• from consuming project using version 1.5: warning: Obsolete as of 2.0.0.0. Use Method B.
• from consuming project using version 2.0: error: Obsolete as of 2.0.0.0. Use Method B.

The compiler would emit a warning until the assembly version was at or greater than the specified version, at which point it would behave as if IsError was true, signaling the dev team to remove the API (or revise their plans).

An additional overload could include the existing isError, to indicate use is always an error, and add a removal message on reaching the specified version:

// ObsoleteAttribute(message, isError, major, minor = 0, build = 0, revision = 0)
[Obsolete("Use Method B.", true, 2, 1)]

• from declaring project version 2.0: error: Obsolete as of 2.1.0.0. Use Method B.
• from declaring project version 2.1: error: Obsolete as of 2.1.0.0. Use Method B. [At declaration site, include "Remove this API to resolve error." and VS could offer a code fix.]
• from consuming project using version 2.0: error: Obsolete as of 2.1.0.0. Use Method B.
• from consuming project using version 2.1: error: Obsolete as of 2.1.0.0. Use Method B.

While this presents a compiler change and a change to ObsoleteAttribute, I suspect it's backward compatible (in the sense that down-level compilers should be able to see IsError normally, set to false), and otherwise presents no changes to the language itself.

[yaakov-h]

IIRC this can be done with a custom attribute and a Roslyn Analyzer at the moment.

This would negate the need for a language change, and for all of your library's consumers to upgrade to a newer compiler that supports your proposed ObsoleteAttribute-with-version.

[erik-kallen]

I love this idea!

It would be so nice to remove all my #warning Remove in next major version from my code. However, I think that the messages for the declaring site should be

• from declaring project version 1.5: no message
• from declaring project version 2.0: warning: Obsolete as of 2.0.0.0. Use Method B.

[kfarmer-msft]

@erik-kallen : You want warnings early, so you can make the changes to Method B at something other than last-minute.

@yaakov-h : You could, provided that it was part of an OOB experience in the main deployment package: Obscure packages might prove solvability, but they don't actually solve. Hence the suggestion for a change to the compiler, and to the existing attribute.

[kfarmer-msft]

One counter-suggestion would be to say this should be an IDE feature instead: VS can surface TODO, HACK, and other arbitrary comment text. But it never presents them as build warnings, let alone errors. And so they generally get ignored. But I also don't see VS ever implementing a feature like this (they would have an entirely reasonable argument to say that build warnings and errors are strictly a compiler issue, and I'd agree with them).

[CyrusNajmabadi]

@kfarmer-msft You can already build this yourself with attributes+analyzers. Is there a reason this need sto be in the compiler? Your rules seem pretty specific to your needs. So it would likely be best if you guys codified it yourself as appropriate.

You could, provided that it was part of an OOB experience in the main deployment package

Analyzers support this. Just package them with your library.

[erik-kallen]

@kfarmer-msft I do not suggest changing your proposal for the usage site, but I don't see why the declaration site should generate a warning until version 2. However, if any methods in the same project use the obsolete method, they should get the same diagnostics as users in other assemblies do.

@CyrusNajmabadi I don't agree that this is specific to someones needs. It is is a useful feature for anyone that uses semver, which should be everyone.

[CyrusNajmabadi]

semver is unrelated to C#. So thsi would be on anyone in the community who wanted to create a semver analyzer to encode those rules and whatnot. It's not really relevant to C# to design something at the language level for that.

It is is a useful feature

No doubt. I never said it wasn't useful. But the bar for getting into the language is not if it's useful. Note that Analyzers/Attributes were literally designed with this sort of thin being a core use case. It means that instead of the cost being incurred in the slowest and most conservative part of the toolchain, it can instead be picked up orthogonally by any other group out there that finds enough value here.

[erik-kallen]

@CyrusNajmabadi In your citation of me, you left out the most important part:

It is is a useful feature for anyone that uses semver, which should be everyone

[HaloFour]

@erik-kallen

He called out semver. Whether or not everyone should use it doesn't make it a part of the C# language. And while it is useful, it's also achievable without modifying the C# language and BCL to support.

[miloush]

I am worried about 3rd parties arbitrarily introducing compile errors into my code.
Moreover, it does not prevent invoking the method by reflection, so it might work for some but not for others.

And if the feature would prevent callers from compiling, it sounds like the method could be not required to have an implementation.