Why different operators?

[5t0v]

Why did you choose to have both +. and + etc. Could you not find the correct type during compilation. It seems like a good candidate for reducing the complexity.

[lpil]

Good question, thank you!

Currently all syntax bar record and tuple access are specialised to a single type, there is no other overloading. This means that we can unambiguously perform type inference without annotations.

pub fn add(x, y) {
  x + y
}

If + is an overloaded operator what are the types of x and y in this function?

We would need to have an answer for this in order to have overloaded operators. This is a solvable problem but we need to be happy with the solution. It is easy to add overloading, it is hard to change it or to take it away, so it pays to be conversative when adding new language features.

[5t0v]

Regarding the example. Don't we already know the type of x and y during compilation? They need to be defined somewhere and passed to the function, and the return value of the function would need to match the context it is used in.

I understand your point. It is harder to take it away, and there are probably concerns that I don't know about.

[lpil]

Regarding the example. Don't we already know the type of x and y during compilation?

Not always, no. If there is a module (or even an entire package) with just the above code we would not have any call sites with which we could infer the type.

To make things more complex if we infer that information from the callsites we would need a way to add constraints to type variables to say "this is an int or a float, but we don't know which yet".

[5t0v]

Thanks for the explanation. I see that the work required to keep track of the contexts that the variables are used in (int or float) will add some complexity.

[lpil]

I think it is likely that we will have one set of operators in future, and I have some ideas for how the overloading will work, but I'm waiting to see if anything better arises :)