Let’s start with something trivial. Here is a point, I would like to make why assignment operator overloading could be useful. It’s only about ergonomics. And maybe it does not justify, as problems emerge that cannot be solved by overloading alone.

Suppose we want to write the result of a multplication matrix*vector into a buffer. One would write it this way:

```
let y = &mut [0;4];
let x = &[1,2,3,4];
let A = &matrix!(
[1,0,0,0],
[0,1,0,0],
[0,0,1,0],
[0,0,0,1]
);
mul_matrix_vector(y,A,x);
```

But if the multplication `A*x`

returns some wrapper

```
struct MulMatrixVec{A: &Matrix<i32,4,4>, x: &[i32;4]}
```

and one could overload the assignment operator, it would be possible to write:

```
y = A*x;
```

So, that’s half baked. In general it would be nice to build some AST on the right hand side *at compile time* and then flush it into a buffer by the best combination of BLAS operations, maybe with some BLAS extensions.

Now, some value shall be an argument to a function. One would first write it into some buffer. Again, writing things inline is not possible or unelegant, as expressions would become cluttered with buffers. The general problem emerges, how buffers could be stated implicitly.

Maybe by introducing an extension language:

```
la!{y = f(A*x);}
```

That could be too much for procedural macros, as an AST with type information might be needed.

Otherwise readability suffers a lot:

```
mul_matrix_vector(buffer,A,x);
f(y,buffer);
```

Abstracting from linear algebra, the problem emerges, how buffers could be stated implicitly, or how pretty expressions could be stated that compile into alloaction free code.

I have the Idea, that a buffer could be bound as a closure binding, i.e. by partial application. But again, what comes out will possibly be half baked, complicated and clumsy.