Ban classes that incompatibly refine type params #14820
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Where "incompatibly" means outside of sub/supertypes. Intending to resolve #11834. Actually, it's resolving what the "Towards Improved GADT Reasoning in Scala" paper calls "an Old Paradox". (cc @LPTK and @Blaisorblade).
But I had to change the check because invariant refinement only was too strict for some legitimate cases, from the various strawman collection ideas in the test suite. So I came up with another way of checking, which seems to pass all the tests, which compares the combined basetype with the basetype without any parts of the type the involve the middle class.
Sent a draft for some early feedback on how best to do the
baseTypeWithout
part. Now I need to make use of this ban in GADT reasoning, see the tests I copied into disabled.