On Fri, Feb 21, 2025 at 08:35:54PM +0900, Alexandre Courbot wrote: > On Thu Feb 20, 2025 at 9:14 AM JST, John Hubbard wrote: > > On 2/19/25 3:13 PM, Daniel Almeida wrote: > >>> On 19 Feb 2025, at 17:23, Dave Airlie <airlied@xxxxxxxxx> wrote: > >>> On Thu, 20 Feb 2025 at 06:22, John Hubbard <jhubbard@xxxxxxxxxx> wrote: > >>>> On 2/19/25 4:51 AM, Alexandre Courbot wrote: > >>>>> Yes, that looks like the optimal way to do this actually. It also > >>>>> doesn't introduce any overhead as the destructuring was doing both > >>>>> high_half() and low_half() in sequence, so in some cases it might > >>>>> even be more efficient. > >>>>> > >>>>> I'd just like to find a better naming. high() and low() might be enough? > >>>>> Or are there other suggestions? > >>>>> > >>>> > >>>> Maybe use "32" instead of "half": > >>>> > >>>> .high_32() / .low_32() > >>>> .upper_32() / .lower_32() > >>>> > >>> > >>> The C code currently does upper_32_bits and lower_32_bits, do we want > >>> to align or diverge here? > > > > This sounds like a trick question, so I'm going to go with..."align". haha :) > > > >>> > >>> Dave. > >> > >> > >> My humble suggestion here is to use the same nomenclature. `upper_32_bits` and > >> `lower_32_bits` immediately and succinctly informs the reader of what is going on. > >> > > > > Yes. I missed the pre-existing naming in C, but since we have it and it's > > well-named as well, definitely this is the way to go. > > Agreed, I wasn't aware of the C equivalents either, but since they exist > we should definitely use the same naming scheme. IIUC, we're still talking about extending the u64 primitive type. Hence, I think there is no necessity to do align with the corresponding C nameing scheme. I think this would only be the case if we'd write an abstraction for the C API. In this case though we extend an existing Rust type, so we should do something that aligns with the corresponding Rust type. In this specific case I think it goes hand in hand though. - Danilo
