Use std::sync::LazyLock instead of once_cell::sync::Lazy

[Rastler3D]

Replaced once_cell::sync::Lazy with std::sync::LazyLock. The standard library's LazyLock provides equivalent functionality and avoids the need for an external dependency.

[Canop]

The problem is that it then requires rust 1.80.

Requiring such a recent release is often a problem as it makes the library unavailable for whole platforms (exemple).

[FalkWoldmann]

Since version 1.80 was released roughly half a year ago, do you have any schedule in mind when to bump the MSRV?

[Canop]

May be quite soon but still undecided.

May I ask why you'd like this change ? The downside is obvious: whole programs not being able to compile with the new version of lazy-regex on some platforms. Many crates fix their MSRV for their own real reasons and they would be impacted by lazy-regex bumping its own. But what real upside is there for you in having lazy-regex not use once_cell ?

[FalkWoldmann]

We could get rid of one dependency, but since my project is sufficiently large, I depend on once_cell anyway, so you are probably right, so it would only makes sense to move ahead with this once other large crates like tracing replaced the dependency

[EdJoPaTo]

Using OnceLock could be an alternative as it's available from earlier Rust versions, but it also requires a bump of the MSRV to 1.70.

Personally I prefer to keep the additional, single dependency over bumping the MSRV for that. Especially with the parallel building a single crate doesn't make a big difference in many projects and the availability for older Rust versions is way more helpful.
Personally would keep the MSRV to something that's supported by the Rust version on Debian stable (currently 1.63) until the next Debian stable is released (hopefully >= 1.85 with edition 2024). Which would mean to keep this PR open for another half a year or so until Debian trixie is released. But thats only my thoughts what I would do.

Also, with the new dependency resolver stabilized in 1.84 (resolver = "3", will be default in edition 2024) cargo picks dependencies suitable for the rust-version. So this crate could update and cargo would not use the updated version for older rust-versions as it's not yet supported. That will simplify a lot of these issues in the future.