Small side note: Always use fully qualified namespaces when referencing types, i.e. ::std::string::String instead of String. It's quite simple to break macros, that don't do that. The same goes for calling methods, as well, sadly. One can implement a trait for a foreign type and the trait has a method that is already present in the type, i.e. suddenly <type>.method() syntax doesn't work anymore and you must use Type::method(<type>) to work around the naming conflict. Depending on the macro, you might be able to use use somewhere to get around the fully qualified namespace issue, but method calls are always prone to naming conflicts in macros.
Of course, if you do not intend to share the macro, it doesn't really matter, but projects grow and develop in uncertain ways, that may lead to breaking code, later on, even in a private project. No one wants to deal with a macro, that was written and last touched a year ago to fix bugs. 