3 ms·
I can understand the annoying part of it if that is the way you would do it elsewhere. Don't you feel that it would to some degree go against zig's goal of as l
by olodus 6y ago
I can understand the annoying part of it if that is the way you would do it elsewhere. Don't you feel that it would to some degree go against zig's goal of as little hidden control flow as possible?
And wouldn't it be possible to create something very close to what you are asking for with a bit of comptime coding? Have the function work on a comptime decided type.
I mean I get that you won't be able to use the operator symbols as names and you would lose infix syntax. Is those what you are after?
- banachtarski 6y agoI don’t understand that goal I think is the issue. I have no issues with understanding control flow with just... functions and operators? Sure you can’t glean it from a glance at the textual representation of code you aren’t familiar with, but day to day that’s literally never a problem. We have tools for that. A control flow problem worth solving is understanding async and multithtreaded code. And yes the expressiveness of actual infix operators is, to me, a strict requirement. The language is for humans, not machines after all, and stuff like add(mul(add(a, b), mul(a, c))) for, say, dual quaternion a, b, and c is a non starter. Most of my code would unfortunately become unreadable and there are often no sensible variable names for those intermediate results.