Re: [PATCH v2 00/18] Introduce rust: In xdiff

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2025, 16:47 UTC
Message-ID: <xmqqikhav3i0.fsf@gitster.g>
In-Reply-To: <CAH=ZcbCZXavx52521cFHdXZn=BCWBiR1aG10ekZVg3PVVJb2VA@mail.gmail.com>

Ezekiel Newren <ezekielnewren@gmail.com> writes:

Show 8 quoted lines

>> > I wanted feedback on:
>> >   * Cleaning up Rust type name collisions
>> >   * People don't like it, so I'll drop that
>>
>> I don't have a strong opinion on this. If it creates issues I personally
>> don't mind fixing it.
>
> Junio doesn't like it, so I'm not going to do it.

It was not "I do not line u16 as a typename when a perfectly well established uint16_t is available", though.

It was more about asking to explain the reason behind insisting to use u(8|16|32|64) types in C code. Perhaps there is a compelling reason to do so that I was missing.

I know that the kernel has used these types for a long time, but that way predates their more recent flirt with Rust. If your answer was "the kernel uses them", then I'd want that answer to cover a few additional questions, like

 - Have they benefitted from their use of u(8|16|32|64) when they
   started working with Rust and if so how?

 - Would we be expected to reap the same benefit if we used these
   types?

for example.

Thanks.