Just use only std atomic without portable-atomics?

[repi]

Seems even when using the std-atomics feature the portable-atomics crate is still included and required as it is part of the public interface? And not re-exported in the crate either so users metrics with 64-bit counters have to manually import that crate with the matching version (0.3, latest is 1.0 which is incompatible).

This feels somewhat backwards, would it be possible that purely std atomics are used by default without bringing in portable-atomics (as in reverse the feature flag)?

cc @MarcusGrass

[tobz]

@repi We use portable-atomic to ensure we support both 32-bit and 64-bit platforms without issue, and we have to provide the implementations of CounterFn, etc, in metrics, due to the orphan rule... and so we need to provide portable-atomic implementations of the traits without having them behind a feature flag.

Thinking it through, maybe there's something we could do with build scripts, but the one thing I'm not clear on is whether or not we could also conditionally bring in portable-atomic is the build script determines it's needed.

Ultimately, while I'm sympathetic to reducing transitive dependencies, this was added to make metrics usable on more platforms, and the cost of compiling portable-atomic feels small enough that I'm not willing to make another feature flag-based change in this area. I'm going to leave it as-is unless some solution like the one I posit above can be made workable, or some other solution that allows providing portable-atomic usage transparently can be figured out.

[repi]

thanks. if it is just for 32-bit platforms portable-atomic is really needed then one should be able to use:

[target.'cfg(target_pointer_width = "32")'.dependencies]
portable-atomic = "0.3"

did that in PR #347 which think would work well and resolve this?

[tobz]

Fixed via a3a706b / #347.