Remove the explicit IEquatable implementation from the IntPtr/UIntPtr reference API#35256
Conversation
|
Yes that one. I would have expected the build to fail since the implementation was implicitly implementing |
|
Yeah that seems like a bug in |
|
I believe that's still compatible both ways, so APICompat seems to be doing its job. If GenAPI somehow still produced the explicit interface implementation that'd be a bug for certain. |
|
APICompat isn't a differ: the fact they are implemented differently isn't really relevant. APICompat's aim is to detect the cases where someone compiling against one assembly and running against a different one will encounter a problem. It's specifically trying to be tolerant of differences that are compatible. In the case of an explicit interface implementation in one case that was made implicit in another, can you describe the scenario that would be broken (reflection doesn't count)? I believe its a compatible change to implement an interface implicitly that was previously implemented explicitly. |
Right, but going the other way is not. So the problem I'm seeing is that we changed the implementation from explicit to implementation and then APICompat didn't flag that the interface was still explicit in the reference which would be breaking. |
|
The reference had both explicit and implicit which I believe is compatible. If you think it’s breaking please describe the precise scenario that would break and how it breaks. To use an explicit interface the caller must cast. That code still works without recompile if the implementation is only implicit. Since the ref still had implicit methods then direct call without cast also still works. |
The implementation API was removed (made implicit, rather than explicit) but not the reference API