Support multiple dispatch for operators

[DartBot]

This issue was originally filed by Sebastian.Por...@gmail.com

---

Math in 3D graphics at the moment requires a complex API for different object types. Adding multiple dispatch at least for overloaded operators would solve this problem.

example code:
mat4 M1 = new Mat4();
mat4 M2 = new Mat4();
vec4 V1 = new Vec4();

M1M2 and M1V1 should be handled with different functions and return different object types. Currently both would be handled by the operator+ in Mat4 class. It is required to either detect object type on runtime and pass it to the correct function or to ignore operators completely and fallback to JS-like:
multiplyMat4Mat4(M1,M2);
// and
multiplyMat4Vec4(M1,V1);

It's certainly possible to replicate multiple dispatch in JS by generating different function names during compilation. It would require an additional runtime detection (the same that would make current operators more useful).

As a game developer I often have a hard time with JS, I would be very happy to see that Dart solves such problems (as it does in many other situations).

[floitschG]

I don't think that we will support method/operator overloading, but there are two ways something similar could be implemented:

1. double-dispatch (which would already work now). This approach is the most flexible and should work great in this context. It adds some boiler-plate, though.
2. pattern matching switching on the operand-type (issue Add pattern matching support #35, issue Destructuring Assignment #75).

Marking as Enhancement request and assigning to Language-area, so that Gilad can make the final call.

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[munificent]

For what it's worth, I'd really like the double dispatch pattern supported too. I've defined Vector types in Dart (mainly for games), and not being able to symmetrically support scalar operators on them is annoying sometimes.

[gbracha]

Multiple dispatch is problematic from a modularity point of view. It requires a closed world assumption. It adds significant complexity to the implementation as well. I don't expect to support this.

---

Set owner to @gbracha.
Added WontFix label.