Skip to content

Remove the explicit IEquatable implementation from the IntPtr/UIntPtr reference API#35256

Merged
tannergooding merged 1 commit intodotnet:masterfrom
tannergooding:ref-api
Apr 22, 2020
Merged

Remove the explicit IEquatable implementation from the IntPtr/UIntPtr reference API#35256
tannergooding merged 1 commit intodotnet:masterfrom
tannergooding:ref-api

Conversation

@tannergooding
Copy link
Member

The implementation API was removed (made implicit, rather than explicit) but not the reference API

@tannergooding
Copy link
Member Author

@ericstj, @safern. Seems GenAPI misses this difference?

@safern
Copy link
Member

safern commented Apr 21, 2020

@ericstj, @safern. Seems GenAPI misses this difference?

You mean APICompat?

@tannergooding
Copy link
Member Author

Yes that one. I would have expected the build to fail since the implementation was implicitly implementing IEquatable but the reference was explicitly implementing.

@safern
Copy link
Member

safern commented Apr 21, 2020

Yeah that seems like a bug in APICompat I don't know it was by design though. @ericstj might know.

@ericstj
Copy link
Member

ericstj commented Apr 21, 2020

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.

@ericstj
Copy link
Member

ericstj commented Apr 21, 2020

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.

@tannergooding
Copy link
Member Author

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.

@ericstj
Copy link
Member

ericstj commented Apr 22, 2020

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.

@tannergooding tannergooding merged commit 484c7ba into dotnet:master Apr 22, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
@tannergooding tannergooding deleted the ref-api branch July 1, 2025 14:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants