On 2024-11-22 at 08:25:23, Jeff King wrote:

OK, here's a quick and dirty conversion that applies on top of Taylor's
patches 1 and 2 (and then patches 3 and on would need to adjust to the
new world order).

There are quite a lot of spots that needed to be adjusted, but the most
part it was just s/->\([a-z]\)_fn/->fn.\1/.  (I'll leave adjusting the
unsafe_ variants as an exercise for the reader).

Yeah, I saw that there were about 50 callers of the hash functions,
which on one hand isn't too many to change, but on the other hand also
surprised me.  I don't remember there being that many callers when I did
the SHA-256 work, but it could be that I'm remembering poorly.

The naming convention was just what I made up, but one nice effect is
that it replaces "_fn" with "fn.", so the line lengths remain the same.
:) It does mean there's a function called "final", which is a keyword in
C++. I don't know if that matters to us or not (I feel like we were
trying to avoid those, but it appears as a function elsewhere, too).

It doesn't.  I think we had one contributor trying to make the code
compile as C++ at one point, but it definitely doesn't now.  A quick
`git grep` show that we have lots of variables named `new` as well.  (In
addition, the implicit cast of `void *`, such as from `malloc`, to a
pointer of any type is not allowed without a cast in C++, so that would
need to be handled, too.)

So I dunno. It is a one-time pain, but I think the result harmonizes the
type system with the concept better.

Yeah, I agree.  It definitely looks like it could mostly be done with a
Perl or Ruby script, even if slightly inconvenient.  And if there is a
conflict, it should be easy to fix up.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA