> So there is just no way to refer to the User struct outside of the function scope, right?... no matter what tricks you come up with, treat it as that (in cas

> So there is just no way to refer to the User struct outside of the function scope, right?... no matter what tricks you come up with, treat it as that (in case of it being associated to a type treat it as a anonymous type accidentally expose) also please _never_ place a module in a function, for various subtle reasons it's technically possible but you really really should not do it I mean in general limit what items (types, impl blocks) you place in function to very limited cases. If you have a type complex enough so that you need a builder defined in a function you are definitely doing something wrong I think. > Does this mean generating child modules for privacy in macros is generally a bad idea? It depends... IMHO if we look at derive like macro usage, yes it's always a bad idea. Derive like thinks should mainly generate impl blocks, if it really really is necessary types and only if there really is no other way modules. Furthermore they should if possible not introduce any of this in the scope. E.g. it's a not uncommon pattern to place all generated code in `const _:() = {/here/};` which is basically a trick/hack to create a new scope similar to a function scope into which you can place items (functions, imports, types, impl blocks) without polluting the parent scope (and yes that doesn't work for modules they are always scoped by other modules). So does that mean the builder derive does it all wrong? I don't think so sometimes you need to do bad decisions because there are no good solutions.