I'm not disputing that some people like user-controlled operator overloading (Zig does have + etc. for vectors), but clearly others prefer no user-controlled overloading of any kind (don't know what the LLMs prefer, if they have any preferences at all). In the safety-critical space where I once worked, where people could get hurt or die if there's a stack overflow, the more common preference was against (user-controlled) overloads or any implicitness. That's why we need options.

▲ dnautics 2 days ago | parent | next [-]

I think zig would do to have "custom binary operators" which is not operator overloading, but basically give people what they want. It would suffice to be syntactic sugar elaborated by the parser. For example:

    const @<+> = @import("op.zig").special_add;

    const c = (a <+> b);
    //syntactic sugar for @<+>(a, b)

	▲	pron a day ago \| parent [-]
		Maybe it will add that. But just how important that is, though, I'm not so sure. Languages like Java, C, and Go don't currently offer custom infix operators, and they are more popular than many languages that do. Note that there are some complexities, though, to infix operators regarding the order of operations (e.g. + vs * in ordinary mathematical notation) and associativity (e.g. is `(x <+> y) <+> z` equal to `x <+> (y <+> z)`?). They can be dealt with, of course, but not without adding complexity that may or may not be worth it.

▲ clhodapp 2 days ago | parent | prev [-]

Fair, but don't conflate custom operators with overloading just because C++ happened to have one very specific way of implementing custom operators.

	▲	2 days ago \| parent [-]
		[deleted]