7 ms·

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd type

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target. Note how terrible doing any amount of math is in C.

menaerus 4y ago
Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.
- Someone 4y ago
  > without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) vector3D a = … vector3D b = … promise<vector3D> c = addLazily(a,b) print c.x in the end, could do the equivalent of print a.x + b.x I think you could make a modern C++ compiler do that for this simple example.
  - menaerus 4y ago
    Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.
    - Someone 4y ago
      Where do you see dynamic memory allocations being needed in that example? I only see locals that a good compiler can fairly easily optimize away. Also, there’s a simple bijection between expressions with operators and two-argument function calls: a + b * c +(a, *(b,c)) plus(a, times(b,c)) Because of that, I don’t understand why operator overloading should give better optimization opportunities than function calls.
      - menaerus 4y ago
        Unless you're talking about some theoretical promise, C++ promise implementation imposes dynamic allocation.
- kazinator 4y ago
  Operator overloading is syntax; lazy evaluation is semantics.
  - menaerus 4y ago
    That is true but a little bit unfair comment because I expanded with the context in the very next sentence. Or perhaps you're aware of alternative way of how to implement lazy evaluation without expression templates and operator overloading with all of its advantages?

menaerus 4y ago

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

Someone 4y ago
> without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) vector3D a = … vector3D b = … promise<vector3D> c = addLazily(a,b) print c.x in the end, could do the equivalent of print a.x + b.x I think you could make a modern C++ compiler do that for this simple example.
- menaerus 4y ago
  Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.
  - Someone 4y ago
    Where do you see dynamic memory allocations being needed in that example? I only see locals that a good compiler can fairly easily optimize away. Also, there’s a simple bijection between expressions with operators and two-argument function calls: a + b * c +(a, *(b,c)) plus(a, times(b,c)) Because of that, I don’t understand why operator overloading should give better optimization opportunities than function calls.
    - menaerus 4y ago
      Unless you're talking about some theoretical promise, C++ promise implementation imposes dynamic allocation.
kazinator 4y ago
Operator overloading is syntax; lazy evaluation is semantics.
- menaerus 4y ago
  That is true but a little bit unfair comment because I expanded with the context in the very next sentence. Or perhaps you're aware of alternative way of how to implement lazy evaluation without expression templates and operator overloading with all of its advantages?