The simplest possible method syntax in C

I’ve been thinking a lot about language design lately. Part of this comes from my quite successful acquisition of Go and my mostly failed attempt to learn Rust. These languages make me question premises I’ve held for a long time, and that questioning has borne some fruit.

In the remainder of this posting I will describe a simple syntax extension in C that could be used to support a trait-centered object system similar to Rust’s (or even Go’s). It is not the whole design, but it is a simple orthogonal piece that could fit with several different possible designs.

Suppose we have two structs named snark and boojum and a function that takes one of each. That is:

struct snark {
/* stuff goes here */
}
 
struct boojum {
/* other stuff goes here */
}
 
int conjugate(int x, struct snark *, int y, struct boojum *, int z);
 
struct snark s;
struct boojum b;

Then my proposal is this: under almost all circumstances, the compiler

should automatically perform the following transformations::

s.conjugate(1, 2, &b, 3) -> conjugate(1, &s, 2, &b, 3)
b.conjugate(1, &s, 2, 3) -> conjugate(1, &s, 2, &b, 3)

That is, if the compiler encounters an attempt to evaluate a structure member reference followed by an argument list, for a member that doesn’t exist in the structure (that’s the “almost”), it looks for a visible function with the right name, and then tries to apply it to transform the method-like syntax into an actual method call.

The rule will fail unless the actual arguments match all of the formal argument types of the function in the right order, except that one actual argument is missing. It will also fail unless the one formal without a corresponding actual has any type other than address of the structure for which we are synthesising the method call.

(It has to be address of, otherwise these method calls could never mutate the instance – they’d get an arg-stack copy of it instead.)

I think I got this idea by miscegenating a recent language called Julia with Rust’s method syntax and some dim memories of CLOS. It has a couple of interesting advantages:

1. No front-end modifications or new syntactic tokens are required – it can be implemented entirely as a transformation on abstract syntax after parsing.

2. Entirely upward-compatible with plain C – if you try to feed this to a compiler without the extension it will break noisily at compile time.

3. Same function can be a method of multiple structures without the requirement that you make an articial commitment to which one “really” owns it. (I find this comes up remarkably often.)

Of course, as I mentioned up front, this is not an entire object system. Conspicuous by its absence is inheritance or a trait/interface system. The final advantage of this proposal is that it would not foreclose or complicate any of those alternatives.