Open BoxyUwU opened 1 year ago
This deep dive will be taking place on 28/8/2023. It was scheduled here
this took place but imo did not have a satisfactory ending so not closing this
Things to cover in a future deep dive:
type_id
and type_name
: rust-lang/rust#97156. Some of the proposed solutions would actually make less fn ptrs types equal to each other which is the opposite of what this PR is trying to do. Are we comfortable with coherence and elsewhere having such a large difference (or any difference) in what counts as equality between two types.
Sized
which every type parameter is implicitly bounded by, that is not implemented for types syntactically containing higher ranked fn ptrs so that it is simply not possible to call type_id/type_name on them. (I have absolutely no idea how this would be possible to do in a backwards compatible way...) We should avoid making complex decisions about equality of higher ranked types without ensuring it will interact nicely with however rust-lang/rust#97156 is solved.
Summary
I would like to have a deep dive to discuss
Rationale
rust-lang/rust#112999 has an FCP and it does relatively complicated changes to a future compat lint that atleast myself am rather unclear on whether its accurately stating breakage we want or not. Personally I tend to see this future compat lint as "buggy" rather than something we actually we want to turn into a hard error.
We also have an open soundness bug rust-lang/rust#97156 that is highly related to the changes that rust-lang/rust#112999 is making, some of the solutions to the soundness bug are even going in the opposite direction than rust-lang/rust#112999 and the future compat lint and explicitly wanting to allow those impls.