Operator Overloading

[nicolasessisbreton]

I know operator overloading is considered out of Zig scope.
But no issue seems to make the following case so here it is.

Operator overloading matter in scientific computing

Consider writing polynomial addition with function

p = 2*x*y + 3*z + 5y - 8*x;

assume x, y and z are some other complex polynomials.
With functions, this becomes

p = sub(add(add(mul(2, mul(x,y)), mul(3,z)), mul(5,y)), mul(8,y))
Is the intent clear in the previous line?
Isn't forcing the previous line on user breaking Zig simplicity principles?

Zig promises to make scientific computing easier and fun

When writing numerical code in C++, memory leak is a pain.
With Zig focus on no 'undefined behavior', writing fast numerical can be made much easier.
C++ is currently a big entry barrier in high performance numerical computing.

Why 'printf' and not '+'

Zig brings a new paradigm where function previously hidden in the compiler internal are now in userland.
Why limit this paradigm to standard function call?

Zig offers an all encompassing approach that offers a build system and a package manager.
There are many domain where operator overloading is crucial.
For example, in Fortran '+' is overloaded in the compiler to support vector addition.
If Zig doesn't offer operator overloading, users will either:

• write some complex preprocessor to get it,
• stick with C++.

These two solutions break many Zig principles.

[bnoordhuis]

How should this integrate with error handling and resource management?

1. Error handling: how do you write x = a + b + c when + is overloaded and fallible?

   Example: fn +(a: &const BigInt, b: &const BigInt) !BigInt - i.e., either a new BigInt or an error like error.OutOfMemory.

2. Resource management: zig doesn't have destructors or linear or affine types. What cleans up the intermediate values in x = a + b + c?

[nicolasessisbreton]

1. Error handling

Error aware overloaded operators can either:

• completely stop execution at the first error
• accumulate the error and produce a report at some point
  (for example at the assignment step of x=a+b+c)

The choice between these should be left to the user.

2. Resource management

Resource management should be left to the creativity of users.
The two extremes are:

• immediate destruction
  When x=a+b+c is executed

  • b+c returns a new value that has the attribute temporary=True
  • a + (b+c) returns a new value and destroys the right operand
  • x = (a+b+x) copy the right operand in x, then destroys the right operand

• tape style

  • initialize a tape
  • executex=a+b+c, any temporaries register itself with the tape
  • execute the method tape.clear() to destroy all temporaries

Additional Comments

The points raised by @bnoordhuis are good.
If we look at a biased history of programming languages:

• C was good but not expressive enough, so Fortran, Julia, Python came in.
• The three newcomers added expressiveness, but jailed the user in some other aspects.
• Zig breaks the situation, now a user can:
  • make arrays first-class citizens (as in Fortran), without inventing a new language
  • make a Zig scripting language entirely in Zig (complete bootstrap)

Supporting operator overloading in Zig is one step toward this history.

Will there be too many ways to do the same thing?

This is a non-issue, because we are talking about userland.
Zig provides one way to overload operators, no suprise.
The rest will be inevitably wild, it's normal and needed.

[logzero]

x = a + b + c should be equivalent to x = add(add(a, b), c)

How does zig deal with error handling and resource management in that case?

PS: I am new to zig and I am also one of those keen on operator overloading. ;)

[tgschultz]

My personal feeling is that operator overloading is too far into the "hidden behavior" territory to mesh well with zig. Some thoughts:

//2*x*y + 3*z + 5y - 8*x
var p = sub(add(add(mul(2, mul(x,y)), mul(3,z)), mul(5,y)), mul(8,x))

Could be rewritten to be more readable using type-namespaced fns:

var p = x.mul(y);
p = p.mul(2);
p = p.add( z.mul(3) );
p = p.add( y.mul(5) );
p = p.sub( x.mul(8) ); 

which stays pretty clean with current error handling:

var p = try x.mul(y);
p = try p.mul(2);
p =try p.add( try z.mul(3) );
p = try p.add( y.mul(5) catch y );
p = try p.sub( x.mul(8) catch x ); 

That said, I can see reasons why DSLs in general are desirable. Something like this might be possible to write:

fn ctBigMath(comptime str: []const u8, args: ...) BigInt {
    //...
}

//...

var p = ctBigMath( "2*[0]*y + 3*[2] + 5[1] - 8*[0]" , x, y, z);

where ctBigMath, at compile time, performs the parsing of the DSL and produces code equivalent to any of the above examples.

And if so, then providing functions in the std library to make it easy to write comptime DSL parsers could be a solution to a lot of things like this without adding anything to the language itself.

[kyle-github]

@logzero, @tgschultz I have been playing with some ideas around extending the use of comptime to include an AST rather than just functions and arguments:

fn comptime MathDSL(ast: AST) AST { ... }
var p = MathDSL(2*x*y + 3*z + 5y - 8*x) ;

I had not proposed an enhancement since I do not have this figured out. The idea would be that, somehow (this is the TBD part!), you'd get an AST and be able to descend on it, modify it and return a valid AST. This would allow almost any rewriting. If you could get the types of x and y then the code could figure out what operations to do to transform the equation into something approaching the try version above.

Note that this takes an AST, not a string, and could perform full type checking on the elements.

It is unclear how to tell the compiler to pass in the AST rather than the argument expression result.

[logzero]

My personal feeling is that operator overloading is too far into the "hidden behavior" territory to mesh well with zig.

I guess I am used to seeing operators as nothing more than syntactic sugar for function calls. If it is not a zig thing, so be it. :)

[nicolasessisbreton]

I know we are all busy, but the rational behind rejection may help future projects.

Zig is intended to replace C, but Zig borrows from C++, D and Rust (all of which have operator overloading).

Zig doc saying that operator overloading is in the 'hidden territory' is not really an explanation.

[tiehuis]

This wiki link articulates a bit more on some core tenets which conflict with operator overloading. These would first need to change before I think we could consider operator overloading.
https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F

Summarising the key headings which are applicable:

• No hidden control flow
• No hidden allocations
• Simplicity

I'll let @andrewrk chime in if there is anything extra worth mentioning.

[andrewrk]

Related #427