-
Notifications
You must be signed in to change notification settings - Fork 12
Please consider re-exporting matches and assert_matches from std #22
Comments
I’ve managed to reproduce this. error[E0659]: `assert_matches` is ambiguous (glob import vs any other name from outer scope during import/macro resolution) It’s unfortunate that the compiler does not resolve this ambiguity automatically (favoring the explicit
But it breaks existing users who are now required to add Increasing the MSRV of the crate does not make sense to me: if a user can afford to require a recent Rust they should drop dependency on this crate and use macros from |
I wasn't suggesting that as an ideal solution, just mentioning it as an alternative in case you didn't want to add compile-time detection. Given appropriate compile-time detection, and re-exporting if available or using the existing implementation from
I was suggesting that |
Are you sure that would be transparent? Wouldn’t the user crate also need to opt into instability with a I’d take a PR that adds compile-time detection and demonstrates use in a new |
If |
I don’t expect that to happen either, in this case. I’m saying that it could potentially happen, which is what I believe that either this reexport isn’t transparent, or the stability system is buggy. |
It looks like rust-lang/rust#82913 was resolved by rust-lang/rust#86947, so closing this. |
In addition to having
matches!
in stable, std now hasassert_matches!
in the latest nightly.This results in compile-time errors for users of the
matches
crate if they have a wildcarduse matches::*;
.Would you consider making new versions of
matches
re-export these macros fromstd
if they're available? (Whileassert_matches
is on nightly, this would require some level of compile-time detection; if you don't want to do that, and you don't mind bumping MSRV, this could wait untilassert_matches
is stable.)I've confirmed that re-exporting a macro from the prelude eliminates this breakage: rustc doesn't consider two names to conflict if they're the same underlying item.
The text was updated successfully, but these errors were encountered: