Also, most c++ code is just...ugly. It can really assault the senses, looking at some of the template & indirection abstractions, etc. Rust just looks better, from what I've seen.
This seems kind of inevitable with macros. They help the macro creator write code with new, "better" abstractions, but readers of the code have to learn the semantics of the macro before they can understand what's happening. The built in mechanisms of a language are familiar to those new to a program's code but macros usually hide something significant (otherwise why have a macro).
I've written fancy macros for assembly language programming to support my own looping, iterating, argument passing etc. but I noticed that the other programmers on the team weren't interested in using them.
On the other hand, I'm so grateful to John Wiegley for his use-package macro for emacs lisp.
> readers of the code have to learn the semantics of the macro before they can understand what's happening.
They always have the alternative of reading the expanded code, which is very similar to what the author of the macro could have written by hand instead of the macro.
I had the same feeling with macros intially, but once you wrote a few of them it's ok, and they provide many more guarantees than pure text preprocessing of C/C++.
I think it's the numerous single character lifetime annotations that they are referring to. I agree that this particular bit of code is somewhat hard to parse (as a rust amateur), but that might be alleviated quite a bit with some less terse naming.
That being said, I think Rust macros are much worse compared to C++, if you ignore templates.
Don't get me wrong, I really like Rust. I just think that it's macros make for some of the most unreadable code I've ever seen.