Skip to content
This repository has been archived by the owner on Jan 21, 2023. It is now read-only.

Please consider re-exporting matches and assert_matches from std #22

Closed
joshtriplett opened this issue Mar 8, 2021 · 6 comments
Closed

Comments

@joshtriplett
Copy link

In addition to having matches! in stable, std now has assert_matches! in the latest nightly.

This results in compile-time errors for users of the matches crate if they have a wildcard use matches::*;.

Would you consider making new versions of matches re-export these macros from std if they're available? (While assert_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 until assert_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.

@SimonSapin
Copy link
Owner

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 use over the prelude).

I've confirmed that re-exporting a macro from the prelude eliminates this breakage

But it breaks existing users who are now required to add #![feature(assert_matches)], right?

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 std instead.

@joshtriplett
Copy link
Author

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 std instead.

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 matches if not, this crate would allow people to use these features on older compilers if they needed that, similar to the standback crate.

But it breaks existing users who are now required to add #![feature(assert_matches)], right?

I was suggesting that matches, when built on a nightly compiler that has assert_matches available, could enable the appropriate feature flag and re-export that assert_matches. That would be transparent to the user of matches.

@SimonSapin
Copy link
Owner

Are you sure that would be transparent? Wouldn’t the user crate also need to opt into instability with a feature attribute? After all, it would be affected for example if assert_matches makes a breaking change to its arguments syntax.

I’d take a PR that adds compile-time detection and demonstrates use in a new tests/*.rs file.

@joshtriplett
Copy link
Author

If assert_matches changed syntax in a backwards-incompatible way before stabilization, matches would need to drop the re-export. (I wouldn't expect that to happen.) But otherwise, it should be entirely transparent.

@SimonSapin
Copy link
Owner

I don’t expect that to happen either, in this case. I’m saying that it could potentially happen, which is what #[unstable] is all about. Using an unstable item should require the local crate to opt in with #![feature] even if that item is imported through a re-export in another crate.

I believe that either this reexport isn’t transparent, or the stability system is buggy.

@SimonSapin
Copy link
Owner

It looks like rust-lang/rust#82913 was resolved by rust-lang/rust#86947, so closing this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants