I'd like generators too. You'll notice that yield is reserved (although of course unlike C++ Rust actually can just take new keywords anyway, because it has a way to spell identifiers that are now keywords) so one day Rust will likely have generators.
But you can't have one way to do macros unless that way is proc macros or you're willing to give up on the power of proc macros. The proc macro is just much too powerful (and thus dangerous) to give people something else and have it be satisfactory.
And I don't think auto-clone is a good idea. That's a potentially expensive operation, it's worth taking the time to admit to yourself that you are choosing to pay that price when you use it. This also means when you forgot that you'd need a clone you're reminded there and then (by the resulting diagnostics) to make the decision, whereas with auto-clone in those cases it just mysteriously has worse performance than you expected (because there's a silent clone)
> although of course unlike C++ Rust actually can just take new keywords anyway, because it has a way to spell identifiers that are now keywords
C and C++ introduce new keywords all the time, by prefixing them with "_" and a capital letter. If you want the nice spelling you need to use a header. E.g. "_Complex". "co_await" etc are operators.
It's possible you're one of the two kinds of "C/C++ programmers" and so you've assumed that since this is how C prefers to introduce things it must be how C++ does it too, but not so.
C++ 20 introduced concepts. In C++ 17 "concept" is a perfectly reasonable name for an identifier. Maybe it's a class, a variable, a free function, all fine. In C++ 20 that's a reserved word and can't be used as an identifier.
Rust does not have this problem, a 2015 function named "await" is somewhat annoying to use from Rust 2018 or later where "await" is a keyword, but it's only annoying it isn't actually difficult.
But you can't have one way to do macros unless that way is proc macros or you're willing to give up on the power of proc macros. The proc macro is just much too powerful (and thus dangerous) to give people something else and have it be satisfactory.
And I don't think auto-clone is a good idea. That's a potentially expensive operation, it's worth taking the time to admit to yourself that you are choosing to pay that price when you use it. This also means when you forgot that you'd need a clone you're reminded there and then (by the resulting diagnostics) to make the decision, whereas with auto-clone in those cases it just mysteriously has worse performance than you expected (because there's a silent clone)