const fn Spinlock::new

[CryZe]

It would be cool to have a way to construct a Spinlock in a const context. This would be super useful for a bunch of stuff I'm currently doing.

[CryZe]

Urgh, I guess because lock_api::Mutex is used, this can't actually be done on stable. For parking_lot, you could use lock_api's RawMutex + a more stable compatible Mutex wrapper to get const fn new on stable :(

[phil-opp]

On nightly, this should be possible after enabling the nightly feature. I don't know what exactly is preventing it on stable though.

[CryZe]

I think it's the R: RawMutex trait bound on lock_api::Mutex's impl block that has the fn new

[phil-opp]

Yes, you're right:

error[E0723]: trait bounds other than `Sized` on const fn parameters are unstable
   --> lock_api/src/mutex.rs:106:6
    |
106 | impl<R: RawMutex, T> Mutex<R, T> {
    |      ^
    |
    = note: for more information, see issue https://github.com/rust-lang/rust/issues/57563
    = help: add `#![feature(const_fn)]` to the crate attributes to enable

[phil-opp]

The only way to get it working on stable this that I can think of is to remove the R: RawMutex bound from lock_api::Mutex and a new_const method without trait bounds:

impl<R, T> Mutex<R, T> {
    #[inline]
    pub const fn new_const(raw: R, val: T) -> Mutex<R, T> {
        Mutex {
            raw,
            data: UnsafeCell::new(val),
        }
    }
}

The disadvantage of this approach is that you can create "invalid" Mutex instances this way. You can't do anything problematic with them though since all the methods are only implemented for R: RawMutex.

[phil-opp]

@Amanieu We have the problem that the Mutex::new function of lock_api cannot be made const on stable because it uses trait bounds. What do you think of implementing a new_const method as described in #1 (comment) behind an optional cargo feature?

[CryZe]

Yeah that would work. Alternatively you could do something like this and basically just skip lock_api altogether, but idk if you consider that an option: https://github.com/thomcc/static_locks/blob/master/src/mutex.rs

[CryZe]

But yeah I guess new_const would be the cleanest approach while still using lock_api.

[phil-opp]

I would prefer to keep using lock_api without redefining a custom Mutex type.

[Amanieu]

One possible way around this would be to define NEW as an associated constant of Mutex, which could be used as Mutex::NEW instead of Mutex::new().

[CryZe]

How would that constant be defined? Doesn't it still rely on <R as RawMutex>::INIT, which doesn't work in const context?

[Amanieu]

<R as RawMutex>::INIT works fine in a const context, but not in a const fn context.

[Amanieu]

Ah wait nevermind this won't work since we need val as an input.

[Amanieu]

Hmm I think the only way to get this working on stable would be to use the workaround that @phil-opp suggested (new_const).

[Amanieu]

I'm not opposed to adding it to lock_api as long as the docs make it clear that this is only as a workaround for missing const fn support on stable.