This is a frustrating decision. My use cases for low level languages overlap closely with my use cases for vectors (etc) with operator overloading. It was one of the first things which put a bad taste in my mouth about Zig.
Zig professes to be a C replacement, not a C++ replacement, so leaving out operator overloading is consistent with that design goal. But I agree, I would prefer to program in a language that expresses mathematical relationships more naturally.
(physics_data.velocity + omega * change) * frame_delta_time
to
physics_data.velocity.add(omega.mul(change)).mul(frame_delta_time)
We learn to read and think about math a certain way, which is incompatible with Zig. Also, Zig's design philosophy of "reading code over writing code" is incompatible with the kind of small modification-test-cycles required when doing games, and creative programming in general. So Zig is sort of DOA anyway for that kind of thing.
But I've been using Zig for non-game projects and it's been fantastic, so definitely not "Blind leading the blind" for the overall language design, imo.
math("(v + Ω * c) * Δt", .{ .v = physics_data.velocity, .@"Ω" = omega, .c = change, .@"Δt" = frame_delta_time})
I'd argue though that the real disadvantage to having overloadable arithmetic is that you're limited to one implementation. This is actually my biggest beef with Rust, namely traits/type classes. It locks you into a single implementation when you may want to do something different based on the context. Zig pushes the dispatch decision to the callsite, not a trait subsystem (see how Zig implements hash mays for example). So I'd personally prefer to use a DSL, since it lets me specify what type of dispatch to use.
> It locks you into a single implementation when you may want to do something different based on the context.
If you want differing behavior in a certain context, and if you don't want to use a different method to make the differing behavior explicit (e.g. the `wrapping_add` methods that Rust provides on numeric types), then you can use a different type for that context, e.g. the `std::num::Wrapping` type that Rust provides.
In general perhaps not, but in Zig it definitely does. Zig considers calling a function to change control flow, because it's no longer just an operator but something that can cause side effects, includinh mutating in place. Perhaps control flow isn't the right term, maybe non-trivial would be better?
With regard to wrappers, I personally find them ugly since 1. They bring in indirection, and I have a personal vendetta against unnecessary indirection, 2. Wrapping doesn't compose well and is a pain to shephard between representations, 3. It's harder to make a function generic across different representations, and 4. Wrappers often don't re-export everything available to their underlying value.
x = x.add(step.mul(2)).mod(width) x = imod(iadd(x, imul(step, 2)), width) x = (x + 2*step) % width
If 50% of the code you're working with is using vectors and matrices, not having operators for those parts is quite annoying.
Note that you can have vector operators without overloading, e.g. Odin has built in vector and matrix types.
But personally I think it's better to give the user more power instead of only letting the compiler author pick which types to allow operators on. Like how Java overloads + but only on the String class. Why do they get to do it, but not me?
const @"<+>" = @import("operator_module").plus;
...
const x = (a <+> b);I mean as an avid Lisp fan, I feel like Lisp basically answers the question of how much syntax you need in a langauge. I must admit though, not having to deal with operators precedence is really nice
(mod (+ x (* 2 step)) width)One is to allow the use of simple mathematical symbols as names for functions, instead of allowing only alphanumeric identifiers.
Most programming languages allow only a small fixed set of symbols to be used as "operators", i.e. as function names.
The better solution is to allow any Unicode character from certain categories, e.g. "Sm" and "Po" ("Symbol, math" and "Punctuation, other"), which does not have an already assigned role in the language syntax, to be used as a function name.
Most LISP variants allow the use of various kinds of character symbols as function names.
The second problem is overloading. Overloading must be treated uniformly for any kind of functions, regardless if their names are identifiers or operator symbols, i.e. not like in Java, where forbidding operator overloading was a mistake (that was an overreaction to C++, which allows the overloading of a few "operators" that are not normal functions and whose overloading should not have been allowed, e.g. the comma operator).
The overloading of operators, especially for user-defined data types is something absolutely essential for scientific and technical computing.
The majority of programmers have not been exposed to programs that contain a great amount of computations, so they are accustomed only with simple expressions that contain a few variables.
In scientific and technical computing it is very frequent to have very big expressions, which may contain a large number of operations and variables, where the variables may have various types, like complex numbers, vectors, matrices, complex vectors, complex matrices, or there may be a type system with distinct types for various physical quantities, like voltages, electric currents, capacitances and so on.
Anyone who had to write frequently such big expressions will definitely prefer, both for writing and for reading, to use overloaded operator symbols instead of long function names, which would fill most of the visual space with superfluous characters, obscuring the structure of the big expression.
The third problem is the syntax of function invocation. Most programming languages allow functions whose names are identifiers to use only prefix invocation but for some symbolic operators they allow infix invocation.
Here I also prefer the languages that do not differentiate between functions with alphanumeric names and functions with symbolic names (i.e. operators). There are languages where for any function it may be specified that it must be invoked as an infix operator, if this is desired.
Which is the best between the 3 classic solutions for expression syntax, traditional expressions with infix operators and multi-level precedence rules (like in FORTRAN and ALGOL), expressions with infix operators and a unique precedence rule for all operators (like in APL) and expressions without infix operators (like in LISP), is debatable.
Each of the 3 solutions has advantages and disadvantages, so the choice between them is a matter of personal preferences.
The general technique of SoA is pretty useful both in games and other applications, but of course I cannot speak to the specific use-case you are describing.
That being said, the parent commenter is actually referring to other recent proposals as opposed to existing `@Vector` functionality:
Also does one really need operator overloading? That feels a little strong. I've gotten by with functions just fine.. Does that make the GPU not like me Mr. wise engineer?