Re:C Macro Reflection in Zig – Zig Has Better C Interop Than...
by flohofwoe on Tuesday July 30, 2024 @11:21AM
(#41110026)
I mean, there can always be a function on the TranslateC step which maps 'special case' names (or even translate them to an entirely different name, for instance when there's collisions with Zig reserved keywords):
translateSpecialCaseNames(.{
.{ .src = "ABOMINATIONCase", .dst = "case" },
.{ .src = "NAMESPACED_PascalCase", .dst = "pascalCase" },
});
...in my own language bindings generator, being able to define such special case mappings is actually quite important, mainly for handling that situation where an automatic mapping would result in a reserved keyword.
Re:C Macro Reflection in Zig – Zig Has Better C Interop Than...
by o11c on Tuesday July 30, 2024 @01:41PM
(#41111986)
Reserved words really shouldn't require manual care; "list of keywords in X language" is really easy to handle so you can just append an underscore.
I do think that namespaces need to be semi-manually managed though (likely only at the project level), since often there are things that look like a namespace but shouldn't be treated like one, and it's not always obvious from a single identifier how many words should be treated as the namespace in some styles.
One special case is that sometimes C-ish libraries have class-likes like {Foo, FooBar, FooBaz} where the desired mapping is {foo.Foo, foo.Bar, foo.Baz}.
Unfortunately, we must not forget forget ABOMINATIONCase and NAMESPACED_PascalCase (we could also generalize this to any switch from one convention to another after the first word). I've found they usually are, in fact, identifiable and roundtrippable. I've found the following usually works (it fails for multi-word prefixes or non-leading exceptions, and of course single-word identifiers are ambiguous):
Then for the words-to-convention direction: