regex depends on this crate, which tries to be a bit more conservative with its minimal Rust version, so I'm hoping we can stay conservative here.

@Amanieu What do you think about just dropping the unreachable crate altogether and inlining what you need from there? Sounds like something we should do if it isn't being maintained. If you're amenable to that, I'd be happy to submit a PR for it.

How did my pr break the 1.9.0 CI job? It should be using the latest version w/out this PR?

@Eh2406 It wasn't your PR. The lazy-static crate hasn't been that great about maintaining their MSRV. It's technically 1.21 now, but it wasn't always.

The minimum rust version for this crate is basically dictated by regex, which is it's biggest user.

@BurntSushi I'm fine with just inlining the unreachable functionality since it is very little code.

I inlined the code from unreachable and void, what do you think?

@Eh2406 LGTM. Thank you! Do you want to just update the CI config to be 1.21 to match lazy static so we can get a green build?

Network error, CI why do you hate me?

You can try git commit --amend --no-edit && git push --force which should re-trigger CI.

I closed and reopened. We are green!

Great work! Thanks!

Published in 0.3.6.

@BurntSushi While I have your attention, some of your crates are on my queue for this kind of thing, and I was wondering your opinion of minimal-versions?

Specifically, would you be interested in:

• PR that bump your direct dependencies to work with it? In general I have bean assuming yes from maintainers, but it can meen that I have to work from the bottom up.
• PR that add synthetic dependencies on things in your dependency tree to work with it? In general I have been assuming no unless they want the third level as well. But if yes, it can save me a lot of work.
• PR that add it to CI to test that it works?

Your thoughts?

@Eh2406 I'm generally in favor of having a Cargo.toml that doesn't lie, and I have haphazardly attempted to maintain that by hand, but there's no way I've gotten it correct 100% of the time. So in that sense, yes, I would appreciate supporting minimal-versions. I haven't actually used Cargo's support for it yet, so I don't really know how it feels, but I expect I'd get around to it at some point or another anyway. But happy to move forward with it any time. And if we did, yes, it should be added to CI.

I'm not sure how I feel about adding synthetic dependencies though. Doesn't that mean I'm using a dependency that isn't maintained? If so, I'd rather fix that than work-around it. I care a lot about maintaining high standards for which dependencies I bring in, so if there is an unmaintained dependency somewhere, I'm probably willing to do the work to fix that, whatever it takes. Although, I suppose an alternative explanation is that it might be a dependency that is maintained but doesn't want to support minimal-versions, which might be reasonable. I'm not sure what to do in that situation.

That is entirely reasonable! A major part of this experiment is to find out how Cargo's support feels, and whether it needs to be changed before The Cargo Team recommends it be used widely.