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

[Junio C Hamano <gitster@pobox.com>]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> If a field in a
> struct uses u16 as the name then Rust won't compile, and cbindgen
> can't create the C header file.

Do you mean that cbindgen fails to help us make a C code we have
that says "struct { uint16_t u16; }" to work with Rust?

Declaring "typedef uint16_t u16" would not help such a case at all,
as it would not make "struct { u16 u16; }" an invalid C, and would
not force us to avoid such names that cbindgen may have problems
with.

So regardless of what to do with type names, we would need to adjust
some variable names to avoid clashes with Rust, which I am fine with.

> Using [ui](8|16|32|64|size) as the type in C also spreads
> awareness that those are reserved keywords and should not be used
> as variable names.

We certainly need to train our developers to avoid problematic names
like "u16" just like we do so for "new".

I am skeptical that using u16 as a type would have a good chance to
contribute to that effort (otherwise we would have added "new" as a
type to solve this issue already), but I am willing to be talked
into trying, with a few conditions to prevent unnecessary churning,
i.e. We do "typedef uint16_t u16" and friends, and new and old code
that are written to directly interact with Rust written code would
be better written with u16 and friends, so the same thing is called
similarly across the wall, but we want to avoid replacing uint16_t
with u16 blindly.