ACP: AtomicPtr::null() to create a null-initialized atomic pointer

[orlp]

Proposal

Problem statement

It's really common to want to null-initialize an atomic pointer. Sometimes AtomicPtr::default() can be used, but not in const contexts. And const contexts are really important specifically for AtomicPtrs, so this is a common constraint.

Motivating examples or use cases

This is an incredibly basic operation so I'll just do a code search for:

• AtomicPtr::default: 416 matches
• /AtomicPtr::new.*null_mut/: ~6200 matches
• AtomicPtr::new: ~11100 matches

So from this primitive research we can establish that around half of the time you actually want to null-initialize an AtomicPtr.

Solution sketch

I propose we add the following method:

impl<T> AtomicPtr<T> {
    pub const fn null() -> Self {
        Self::new(core::ptr::null_mut())
    }
}

With this one can simply write:

static MY_PTR: AtomicPtr<u32> = AtomicPtr::null();

Alternatives

One can simply call AtomicPtr::new(core::ptr::null_mut()). It works but is quite a mouthful.

Another alternative would be to add the associated constant NULL to AtomicPtr. There is precedence for associated constants on generic types (e.g. NonZero::<T>::MAX), but as far as I'm aware not for non-Copy types.

Before trying it and seeing that it does in fact work I personally found it a bit confusing how exactly an associated constant would work for a non-Copy type, so my preference would go out to a const null() constructor.

[ChayimFriedman2]

AFAIK libs-api stance in the past was that we should avoid adding a function just because const fn in traits is not possible yet.

On the other hand, this seems useful to me nevertheless, as AtomicPtr::default() isn't clear that it will create a null pointer.

[pitaj]

Should we also add a ::dangling() constructor?

[orlp]

@pitaj There are ~440 matches for /AtomicPtr::new.*dangling/. So there is some usage but significantly more niche than null.