[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kw-3usvn6JfD9Lp5KVrYyCVgOEehM7qXdpTvoDrX5TCw@mail.gmail.com>
Date: Tue, 30 May 2023 16:13:47 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: yakoyoku@...il.com, alex.gaynor@...il.com, benno.lossin@...ton.me,
bjorn3_gh@...tonmail.com, boqun.feng@...il.com, gary@...yguo.net,
jiangshanlai@...il.com, linux-kernel@...r.kernel.org,
ojeda@...nel.org, patches@...ts.linux.dev,
rust-for-linux@...r.kernel.org, tj@...nel.org, wedsonaf@...il.com
Subject: Re: [PATCH v1 6/7] rust: workqueue: add safe API to workqueue
On Tue, May 23, 2023 at 1:07 PM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> I think this is a question of style. For a comparison:
>
> match (queue_work_on)(work_ptr) {
> true => Ok(()),
> // SAFETY: The work queue has not taken ownership of the pointer.
> false => Err(unsafe { Arc::from_raw(ptr) }),
> }
>
> vs
>
> if (queue_work_on)(work_ptr) {
> Ok(())
> } else {
> // SAFETY: The work queue has not taken ownership of the pointer.
> Err(unsafe { Arc::from_raw(ptr) }),
> }
There is also the possibility of using the early return style:
if ... {
return Err(...);
}
Ok(())
This one makes it consistent with other early exits (i.e. whether at
the end of the function or not) and closer to the C side.
It is particularly nice when we are talking about errors, instead of
two "equal", non-error outcomes.
Cheers,
Miguel
Powered by blists - more mailing lists