[Discussion] Change method resolution (for Extension methods) to observe Obsolete attribute
- Dominant language
- No language data
- Stars
- 328
- Forks
- 71
- PR merge metrics
- No merged PRs in 30d
Description
I have quite often come across the scenario where a class has been broken out to extension methods on an interface, or extension methods have been moved from a specific implementation to a separate assembly, or sometimes to a new (more appropriate) namespace etc.
When tidying up the code, the old method (which usually just calls the new extension method) is initially marked Obsolete then Obsolete with error before removing the method.
This allows the existing codebase to run until everything is updated to use the new extension method.
The problem is, that it is not always convenient or even possible to remove the call to the original method due to namespaces etc. and you get a compile error, either `BC30668` or `BC30521`.
It would be really useful if the compiler would use the Obsolete attribute to add an additional priority order for extension methods so it could resolve this and avoid the `Overload resolution failed because ... Extension method : Not most specific.`
I know there is some discussion currently about the Obsolete attribute anyway, and I'm not entirely sure if this is a purely VB issue or whether it is a .Net level compiler issue but I thought I'd flag it here first.
To avoid breaking anything I think the resolution order becomes:
- Local Non Obsolete Method
- Local Obsolete (no error) Method*
- Extension Non Obsolete Method
- Extension Obsolete Method
- _Local Obsolete (error) Method_
- _Extension Obsolete (error) Method_
where the last two won't compile due to the error, but will run if already linked.
* I would prefer this to be after Extension Non Obsolete Method but I think that would potentially be a breaking change?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.