2025-10-01 21:57, Tiago Freire:
> multi_lock seems good enough imo, but you shouldn't get to hung up on it.
> You put in a section discussing naming alternatives and then gives some
> pros and cons of each and give a reasoning why you picked the one that
> you did.
> If someone doesn't like it they can bring it up for discussion, and you
> can ask for a vote between alternative names.
> If a different name is picked you just change it in the next version of
> the paper, no big deal, it's normal for papers to change in this way.
> The name itself does not change the core idea of the proposal, so most
> of the paper should be unaffected by this small detail.

I agree in principle, but I'd like to at least start with a name that
puts as few people at LWGI as possible off and I never really fancied
`unique_multilock` (but couldn't come up with a better myself). Oh well,
perhaps the actual name is a minor uphill battle in case people hates
it. :-)

Br,
Ted

> ------------------------------------------------------------------------
> *From:* Ted Lyngmo <ted_at_[hidden]>
> *Sent:* Wednesday, October 1, 2025 8:59:56 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>; std-
> proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Subject:* Re: [std-proposals] P3833R0a - std::unique_multilock or
> std::multi_lock
>
> 2025-09-10 17:38, Ted Lyngmo:
> > 2025-09-08 08:06, Tiago Freire:
> > >
> > > multi_lock?
> >
> > Not bad! I could absolutely live with that name!
>
> I've thought about the proposals for a good name a lot and I think
> Tiago's is the one I like the most.
>
> one mutex 0-many mutexes description
> +---------------+---------------+-----------------+
> | lock_guard | scoped_lock | always owning |
> +---------------+---------------+-----------------+
> | unique_lock | multi_lock | (*) |
> +---------------+---------------+-----------------+
>
> (*) deferred locking, time-constrained attempts at locking, recursive
> locking, transfer of lock ownership.
>
> What do you think? I have had a hard time rewriting the proposal because
> the actual name is bothering me :-)
>
> `std::multi_lock`, yay or nay?
>
> Best regards,
> Ted Lyngmo
>
> Ps.
> On a sidenote: I have supplied an implementation of the proposal that
> came before P3833, namely P3832R0 Timed lock algorithms for multiple
> lockables, to the Beman project:
> https://github.com/bemanproject/timed_lock_alg <https://github.com/
> bemanproject/timed_lock_alg>
>
>
>