[clang][enhancement] operator overload attribute for C

[olemayu]

Simple and elegant. Just like C itself.

typedef struct vec3 {
    float x, y, z;
} vec3;

[[clang::operator(*)]]
inline vec3 v3v3_mul(vec3 lhs, vec3 rhs) {
    return (vec3) { lhs.x * rhs.x, lhs.y * rhs.y, lhs.z * rhs.z };
}

[[clang::operator(*)]]
inline vec3 v3v1_mul(vec3 lhs, float rhs) {
    return (vec3) { lhs.x * rhs, lhs.y * rhs, lhs.z * rhs };
}

// lhs/self expected to be a pointer for assignment operators
[[clang::operator(*=)]]
inline vec3 v3v3_smul(vec3* self, vec3 rhs) {
    self->x *= rhs.x;
    self->y *= rhs.y;
    self->z *= rhs.z;
    return *self;
}

[[clang::operator(*=)]]
inline vec3 v3v1_smul(vec3* self, float rhs) {
    self->x *= rhs;
    self->y *= rhs;
    self->z *= rhs;
    return *self;
}

[shafik]

CC @AaronBallman

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (olemayu)

Simple and elegant. Just like C itself.

typedef struct vec3 {
    float x, y, z;
} vec3;

[[clang::operator(*)]]
inline vec3 v3v3_mul(vec3 lhs, vec3 rhs) {
    return (vec3) { lhs.x * rhs.x, lhs.y * rhs.y, lhs.z * rhs.z };
}

[[clang::operator(*)]]
inline vec3 v3v1_mul(vec3 lhs, float rhs) {
    return (vec3) { lhs.x * rhs, lhs.y * rhs, lhs.z * rhs };
}

// lhs/self expected to be a pointer for assignment operators
[[clang::operator(*=)]]
inline vec3 v3v3_smul(vec3* self, vec3 rhs) {
    self->x *= rhs.x;
    self->y *= rhs.y;
    self->z *= rhs.z;
    return *self;
}

[[clang::operator(*=)]]
inline vec3 v3v1_smul(vec3* self, float rhs) {
    self->x *= rhs;
    self->y *= rhs;
    self->z *= rhs;
    return *self;
}

[Endilll]

We have a well-hidden documentation listing the criteria for new extensions: https://clang.llvm.org/get_involved.html. In short, you need to speak to C standards committee (which involves writing a paper), post an RFC on our forums (which has to reach consensus), and an implementation of sufficient quality to be merged upstream.

On technical merits, you tackle one of the easier parts, but you completely omit how in expression (vec 3){0, 0, 0} * 1.0 the correct overload will be picked. For the longest time C standards committee avoided dealing with overloads. If you intend on borrowing C++ rules here, then maybe going all the way to a C++ compiler is a better option?

[AaronBallman]

This is something which WG14 has talked about before and the committee's perspective has been pretty sour on operator overloading. The concerns are broadly: 1) it hides the function call from the user and C tends to avoid hiding those sort of details from users (it's also why C is unlikely to ever get constructors, for example), and 2) it requires some form of name mangling to be able to represent the function call in the binary; C is a lingua franca for interop between many languages and having easily predictable function names is important for the language.

We could expose an extension without the committee's blessing, but this extension will likely have quite a bit of impact on the compiler implementation because many of the C expression code paths do not account for the idea of an overloaded operator. So this would be a pretty large feature despite having a lot of the machinery available from C++, which makes it less attractive without committee buy-in.