@thephd @euneuber i did miss that; sorry!
ok, this is cool. I don't like the promotion rules, but some users were bound to ask for them. So i really like the fact that, if they really want it, at least they'll have to explicitly opt into it like this. (And during a code review where it's introduced, it'll be like a big neon sign to anyone reading it.)
Jan 15, 2025, 12:47 AM@JamesWidman @thephd @euneuber it's all fun and games till someone does _Operator(<<, FILE*, const char *, fputs);
@joe @thephd @euneuber ok, yes [edit: no, see below],
BUT
at least it won't be in the standard library.
i mean, at least it seems like a pretty safe bet that the C committee wouldn't put that in the standard library.
like, i'm 99...
80% sure that the C committee wouldn't put that in the standard library.
@joe @thephd @euneuber found the relevant bit in the video, starting at about 58:00, in response to a question about pointers:
[58:45] "[...] the same way you can't override for `int, int`, you can't override it for `int *` or `MyStruct * [...] [A pointer is] still a built-in type, even though it's a pointer to your type."
So, a compiler would issue an error for:
_Operator(<<, FILE*, const char *, fputs);
...because both operand types are built-in types...
Jan 15, 2025, 3:52 PM@JamesWidman @joe @euneuber FILE is not required to be a complete type, so that code might not work everywhere.
It also would only work if you gave it a dereferenced char at the start of the array, not any old pointer.