I've been thinking about a way around this, and I'd be interested to see if comptime with a DSL wouldn't be too unwieldy. Something like

  math("(v + Ω * c) * Δt", .{ .v = physics_data.velocity, .@"Ω" = omega, .c = change, .@"Δt" = frame_delta_time})

I know this is already possible with comptime, though I haven't implemented it yet since I haven't needed vector math in what I'm working on currently. Can't decide whether using math names is better or worse than using the full variable names though.

▲ dnautics 35 minutes ago | parent | next [-]

I have a sibling comment -- having thought about this for a very very long time, zig should really implement binary pseudo-operator syntactic sugar. I don't think this violate zig's spirit of 'no hidden function calls' in that I don't think it takes much of a mental lift to "get" that (_ <+> _) means "heyo this is a function call, not a true operator".

	▲	smj-edison 12 minutes ago \| parent [-]
		At first I was going to say that I disagreed since you couldn't choose what implementation of addition you wanted, but now that I've read your comment where you import the type of addition used, it's growing on me. Would you have operator precedence, or would it be more like Smalltalk's binary operators?

▲ aaaashley 41 minutes ago | parent | prev | next [-]

yes! i had this exact idea. i also thought about integrating geometric/clifford algebra using zig's type system so that you could have one mathematical multivector object instead of complex / quaternion types, etc.

	▲	smj-edison 36 minutes ago \| parent [-]
		That's the other great thing about using comptime, is you can specify which DSL you want to use for which scenario. You're not locked into one implementation.

▲ stouset an hour ago | parent | prev [-]

All this just to prevent people from using + - * / and ^. Why?

	▲	smj-edison 30 minutes ago \| parent [-]
		Andrew talks about it because it introduces hidden control flow where you're expecting simple operators. In Zig anything that deals with control flow is a keyword (including short circuiting and, which is `and` instead of `&&`). 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.