Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add an assert_not_impl macro #17
This is the polar opposite of the assert_impl macro and abuses name
A trait with type parameter
No other ambiguity can occur, only the trait's type parameter is
I needed to modify the design slightly, as the method call was possibly not completely unambiguous. Now the ambiguity has moved to the type parameter of a single locally defined trait which allows us to restrict the set of possibly applicable methods to that trait alone using turbo-fish syntax. By leaving out the trait's type parameter it can only be inferred when one impl is applicable.
This also makes it somewhat simpler as only one type and trait is involved.
nvzqz left a comment
Thank you so much for this!! I was previously convinced that this wasn't possible. I love cursed hacks like these. ❤
Regarding style, please remove whitespace between empty braces.
I'll be more than happy to merge this PR once you've made my requested changes. Also, the changes in this PR should be detailed in
This is the polar opposite of the assert_impl macro and abuses name resolution with trait. A trait with type parameter `A` provides a simple method. The trait is implemented on the checked type `T` potentially twice: with type parameter unit `A=()` for all types `T`, and with another parameter type -abitrarily a new `Invalid`- when the `T` implements the trait bounds. We then try to select `T` as an instance of the trait, using turbo-fish to try and access one of its items, without providing the trait type parameter. When only the first instance is implemented the type checker can infer `A=()` but when the second is implemented as well it can not. No other ambiguity can occur, only the trait's type parameter is ambiguous. Thus, type inference and compilation succeeds if the trait bound is not satisified by the input type.