I was thinking about the partial borrowing issue lately and found that macro methods(better name) can be a nice addition to the language and can make some stuff less dirty, it might be be a bad idea but I would like to discuss it anyway.

So basicly to allow to ‘inline’ code, the rule of thumb is if something compiles fine it should compile fine if we put it in a macro method, and I think it might solve more types of problematic borrowing nicely.

I’m not sure about the return type but thats how I see it working nicely with stuff and with compiler knowing something about the macro method.

This is different to other solutions because macro methods are not functions they are just sugar.

This might be abused and produce harder to debug errors but if used correctly I can see nice abstractions with code that were impossible to do in a nice way.

What @Soni is referring to is that macros are expanded before anything else, so they can only rely on syntax. @Soni then refers to “partially initialized types” because that is a Pre-RFC that would solve your underlying problem.

The reason your code didn’t work is because of lifetime elison rules, due to this impl Iterator<...> and Item gets the lifetime of selfwhich could be longer than the lifetime of divs, but we can fix that with some annotations.

Wait,how is the ability to create types in a macro unhygienic?You can take the identifier of the type you are generating as a parameter.Maybe you meant “always creates a type with a fixed name that escapes the macro”?