Two points that would worry me from a maintenance/onboarding perspective:

• The struct definition does not let you know that there is an impl block. So you have to be aware that these exist. (There can be multiple ones.) So: How do you know, just a looking at the struct definition, which methods are defined for Rectangle? This would make it quite hard for new people to understand what is possible.
• The same is basically true for traits. You do knot know for which types it is implemented.

It seems like a nice idea. In larger projects the use of this feature has to be probably very restricted in order to make it maintainable.

Just my 2 cents.

Is the point that there may be cases where it is better that you don't have to be aware of every impl block? If there is a specific project where it is convenient to add a is_all_whitespace() method to the rust String class you can effectively add that method using impl. That doesn't mean that every rust programmer should use or know about this impl block.

Maybe adding impl / trait ergonomics has less value for cppfront given that cppfront has unified function call syntax where you can call f(x) as x.f(). In this example you could write a function is_all_whitespace(line : std::string) and then using UFCS you could invoke that function in a way that looks like it is a member function: my_line.is_all_whitespace().

Agreeing with what @ktegan said, universal function call syntax and C++'s duck typing already solve the problems that impl would be solving. C++ concepts define a required interface for supplied types, and if the type you're passing doesn't fit that interface, you can write a free function that will be used by that interface with UFCS.