Currently, the IDE is responsible for the feature 'remove unnecessary cast'. This feature itself is enormously complex and has been a very large source of errors for the IDE. Looking just at issues with a false IDE0004 reported, we have more than 60 (and that doesn't count bug reports where the user doesn't mention the specific IDE error code).
The code has always been problematic (especially as it is written as a blacklist instead of a whitelist). This causes us to often aggressively assume a cast is safe to remove, which can have disastrous implications for a program. It is also extremely hard to maintain as the compiler/lang adds more advanced features in this area. In particular, both conditional expressions and target typing have proven to cause huge amount of headaches here as hte IDE attempts to bring our analyzer up to snuff with those advanced, often non-local, lang features. I'm fairly certain that even with all our patches that we've put in so far, we still likely have dozens of issues with the language rior to C#9 and likely dozens introduced post that.
From talking with @333fred we have a supposition that this feature would be a lot simpler, and saner, if placed into the compiler itself. Similar to the Remove unused usings analysis that was done years ago, we can leverage the compiler's rich understanding of the code (including a complete bound semantic tree) to do a much more precise and accurate assessment of if a cast is unnecessary. The compiler would then just issue a hidden diagnostic which the IDE layer would light up on to both fade out hte cast, and offer the fix. (Or, there could literally be a 'IsCastUnnecessary' helper on SemanticModel).
While this is likely a very facile analysis, we think the general idea would be to effectively examine the before and after bound trees for a cast (i.e. one with the cast in it, and one with it not there). The compiler would then whitelist tree changes which were proven to be non-impactful. For example, given:
object o = (object)someString;
this cast would be unnecessary as the trees before and after would effectively be the same (with an implicitly written implicit-reference conversion, versus an explicit one).
Note though that the cases can get very complex as the presence of conversions can affect many parts of compiler analysis (for example, overload resolution). However, this complexity is precisely why IDE would prefer that this be in the compiler, as otherwise the same analysis that the compiler normally does now needs to be redone (often poorly) at our layer.
There is no great rush on this. But it would be very nice to be able to have this be done. Esp. if there are interested compiler devs willing to at least explore this idea and measure the viability of it. Fortunately, the IDE has a large amount of tests (roughly 600+ in this area) documenting many of complex cases that we've often been tripped up by. The tests are split into two test suites:
RemoveUnnecessaryCastTests and
CastSimplificationTests
Currently, the IDE is responsible for the feature 'remove unnecessary cast'. This feature itself is enormously complex and has been a very large source of errors for the IDE. Looking just at issues with a false IDE0004 reported, we have more than 60 (and that doesn't count bug reports where the user doesn't mention the specific IDE error code).
The code has always been problematic (especially as it is written as a blacklist instead of a whitelist). This causes us to often aggressively assume a cast is safe to remove, which can have disastrous implications for a program. It is also extremely hard to maintain as the compiler/lang adds more advanced features in this area. In particular, both conditional expressions and target typing have proven to cause huge amount of headaches here as hte IDE attempts to bring our analyzer up to snuff with those advanced, often non-local, lang features. I'm fairly certain that even with all our patches that we've put in so far, we still likely have dozens of issues with the language rior to C#9 and likely dozens introduced post that.
From talking with @333fred we have a supposition that this feature would be a lot simpler, and saner, if placed into the compiler itself. Similar to the
Remove unused usingsanalysis that was done years ago, we can leverage the compiler's rich understanding of the code (including a complete bound semantic tree) to do a much more precise and accurate assessment of if a cast is unnecessary. The compiler would then just issue a hidden diagnostic which the IDE layer would light up on to both fade out hte cast, and offer the fix. (Or, there could literally be a 'IsCastUnnecessary' helper on SemanticModel).While this is likely a very facile analysis, we think the general idea would be to effectively examine the before and after bound trees for a cast (i.e. one with the cast in it, and one with it not there). The compiler would then whitelist tree changes which were proven to be non-impactful. For example, given:
object o = (object)someString;this cast would be unnecessary as the trees before and after would effectively be the same (with an implicitly written implicit-reference conversion, versus an explicit one).
Note though that the cases can get very complex as the presence of conversions can affect many parts of compiler analysis (for example, overload resolution). However, this complexity is precisely why IDE would prefer that this be in the compiler, as otherwise the same analysis that the compiler normally does now needs to be redone (often poorly) at our layer.
There is no great rush on this. But it would be very nice to be able to have this be done. Esp. if there are interested compiler devs willing to at least explore this idea and measure the viability of it. Fortunately, the IDE has a large amount of tests (roughly 600+ in this area) documenting many of complex cases that we've often been tripped up by. The tests are split into two test suites:
RemoveUnnecessaryCastTests and
CastSimplificationTests