reduce duplicated code

[brody4hire]

While working on PR #260, I noticed what looks like quite a bit of duplicated code. I am wondering if we could find some kind of idiomatic way to make some generic structures & functions to help reduce the amount of duplicated code. I would love to take a look into this at some point.

[matklad]

Perhaps we could reduce duplication indeed, but a hard requirement here is to also simplify the code along the way. Between duplication and more complex code, I would prefer duplication.

[briansmith]

My experience with the race module was that I wanted to vendor OnceNonZeroUsize but not the rest of the file. I believe that OnceNonZeroUsize could be put into a separate submodule and then the rest of the file could be written in terms of its public API. Besides making vendoring parts easier, it would also better encapsulate the use of atomics by using a module boundary to hide the inner parts of OnceNonZeroUsize from the things that are built on top of it.

[briansmith]

I started doing easy parts of this, for OnceNonZeroUsize, in PR #280 and PR #281.

[briansmith]

So, my experience with #280, #281, #284, #285, #286 is that there might be minor improvements that we can make. If you look at those PRs, you will see in many ways they are just changing what's duplicated and what's not duplicated, not really reducing duplication. I suspect that we could model the various atomic types with traits that we would create and then reduce the duplication in each implementation of once_cell's types, but then we'd be duplicating all the boilerplate for implementing the traits. I'm not really sure it is a net win.

Perhaps we could use macros to avoid copy/paste boilerplate, but I doubt it would be a significant (net) benefit.

Regardless, I don't see how having this issue open really helps. We can make improvements on a case-by-case basis without having an issue open.

[matklad]

Agree here! once_cell is a tiny library with a lot of users, so it doesn't matter if we have a bit duplication, but it's critical that we keep the code flat abstraction-wise!