Operating overloading is considered hidden control flow. I appreciate that the team set made and are adhering to principles, but it does not mitigate the downside of this omission to me. I do a lot of scientific and numerical computing, and use vectors frequently. Non-overloaded vector syntax is tough to read and write.
This is what I felt initally, too. However, you easily become used to the lack of overloading, and since the language has method syntax sugar you can easily get used to .add() over +. I'd recommend you give it another shot.
After some thought, I think I know why this is irritating. The domains I imagine Zig would be suited for are also ones where I use vector operations regularly. Almost a 1:1 overlap:
- Embedded (Accelerations, velocities, positions)
- Robotics
- Games
- Performance-critical scientific and numerical code (Cosmology, computational chemistry etc)
- 3D graphics and visualizations
Zig has builtin support for vectors[1], which I think provides some alleviation. But sure, it's not as complete or flexible as a whole vector/matrix library.
Great to know! From the description in that page and yours, it sounds like this is a related, but different concept. Specifically, that page includes use of a `Vec3` of the sort I was implementing, done with a `struct` and methods, vice @Vector.
Sorry I didn't mean to laugh at his effort. I was laughing more like I see this happening on HN in real time sort of mins after trying. I do think he has a point though. Not entirely sure how zig should tackle it or tackling it at all.
Operating overloading is considered hidden control flow. I appreciate that the team set made and are adhering to principles, but it does not mitigate the downside of this omission to me. I do a lot of scientific and numerical computing, and use vectors frequently. Non-overloaded vector syntax is tough to read and write.
I'm aborting. This is an unfortunate decision.