And another thing, you said you had problems running the examples, could you tell me what where those problems?

Also another thing: ever_called is the only way I found to make the compiler notify me when a coroutine is not used. When I forget the co_await in front of a coroutine it simply does not do anything and I'm left wondering why something does not work. ever_called is a hack to alleviate this problem a bit, I would be quite happy to listen to a better solution.

Thank you for your time and effort in writing this review! You've made some good points which I'll try to implement and some others with which I simply disagree: the macros and naming. I've seen code with longer names and code with shorter ones and I find the shorter name code easier to understand and the macros simplify too much of my life. Also, once you understand the macros you can easily look for them as potential 'breaking' points. I did expect a review going over the usage of the library and it's internals but I guess people simply didn't understood what I wrote, I'll keep that in mind.

Ok, I'll keep that in mind.

I have different pod structs with many common fields with the same meaning and I wanted to print them on screen. I will see if I can use it for other things but for now that's what I needed it for.

I can't really find a reason this is a bad idea:std::vector<Type> matrix; Type *operator [] (int index) { return &matrix[0] + index * column_count; } I think I will use it instead of the Type **matrix

You convinced me, I need to change the container. Also changing the way I provide alternative functions like abs and sqrt seems a good idea.

Indeed the last union and the operator where bugs, I'm sorry for that. The unions are accepted by gcc and it is the compiler that I use the most, maybe I should add a gcc tag to the question? I don't know if I want to get rid of it because I really like to be able to use vec.x instead of maybe vec.x(). Dynamic allocation of the container shouldn't fire for small matrix sizes so I think I'm on the safe side. Maybe I should enforce that in code somehow. About replacing the pointer with a std::vector that sounds like a good idea now that I look again at it.

I know, but I use this implementation mainly for learning and so I prefer writing my own matrix implementation, like you said, for learning.