👋

It’s Letter #0, and we’re starting it off with a new feature idea!

If you missed one of the related articles written by our very own “ThePhD”, catch it here. Essentially, the gist of it is that C doesn’t have the built-in language tools to solve some of its most pressing existential problems. This doesn’t mean C (and, by extension, C++) can’t be used to make great APIs, it just means that C’s ability to evolve into something better and handle greater use cases it a little questionable!

For that reason, we’re thinking about actually introducing a new feature to C. We might even get to prototype it out in GCC or Clang! But, the idea is very simple. If you’re used to C++’s “type aliases” or C’s “typedefs”, then the concept here is pretty straightforward for a new feature. Here’s the core idea, using made up syntax:

int a_function (int a, int b) {
    return a + b;
}

using a_function_by_any_other_name = a_function;
// does it smell as sweet?

Essentially, it allows you to provide a “transparent” alias for a pre-existing function declaration. It allows you to interact with that transparent alias like a normal function call:

int main () {
     int value =
          a_function_by_any_other_name(3, 1);
     return value; // returns 4
}

You can even do normal things with it, like take its address or let it convert to a function pointer to pass it as an argument to another function. Note that you can get similar behavior (but not perfect) in C++ using constexpr an references:

int a_function(int a, int b) {
    return a + b;
}

constexpr const auto& by_any_other_name( = a_function;

int main() {
    return by_any_other_name(1 ,2);
}

This means it’s not totally necessary in C++. But for C — which lacks both constexpr and references — it is perhaps the only way to have a non-macro solution to “renaming” functions.

The reason being able to provide transparent aliases is you have to avoid things like Shared Libraries from containing the exact symbol by_any_other_name! This is important for ABI, for example if you wanted to direct a function call to a specific internal implementation but give the user a “standard” name to call. For example, one can map the cos global function to a implementation-specific intrinsic:

using cos = __cosf64;

This is mostly for people in the weeds of implementing heavily-depended-upon libraries, but it also comes in handy for other folk who want to make certain functions available without having to redeclare/rewrite them under a different name and use implementation-defined tricks to have them show up.

A more full specification-like sketch can be found here in this Godbolt, showing the behavior we would want overall. (It doesn’t compile, because it’s a new idea.) Maybe, one day, it will be proposed for standardization in C!

— Shepherd’s Oasis 💙