That's basically called code generation. Visual Studio had it more than twenty years ago in the form of the "MFC App Wizard".
Problem is, what if the macro-generated code had a bug, and it was expanded in 77 different places (not to mention in subtly different ways)? We want to correct the macro in one place and re-expand it.
Writing code-generating code, but then just retaining the results of the generation, is a serious "anti pattern".
I wasn't clear. In the Go community, you don't retain just the results of the generation, you retain the source as well, you just publish the results.
Furthermore, when someone says they're musing about with ideas, "That's an antipattern" isn't a helpful contribution. Why is it an antipattern? Go deep, not just the superficial reasons. The reasons matter, because it may turn out the reasons don't apply, or that it was an antipattern because of specific conditions in the local landscape that may either not apply or could be made to not apply (e.g., functional programming is an antipattern in Go and the only way to work in Haskell, declarations of "antipattern" are almost always only locally appropriate).
Further, what prompted my musing in the first place is that you can convert "That's an antipattern" into the more scientific theory-type expansion of "If you do that, you will produce unmaintainable code." However, in the Go community, to some extent, we see people doing "that" but not ending up with unmaintainable code. (Please do not simply assert that it must be unmaintainable because that's what this antipattern produces, as that is begging the question. I see code that I would not describe as "unmaintainable" coming out of this process. Such as in the very thing that prompted this discussion; there is nothing about an external totality checker that makes the code unmaintainable.) Reality trumps theory. Since the theory that code generation is often a bad idea is indeed fairly well established, that tends to imply that rather than the theory being "wrong" it is incomplete. What if the community has oversimplified its view of code generation? What if there is a particular combination of difficulty and benefit that might allow us to harness it, as I said, to more truly modularize a language in a way that the entire language is not always pressing down on a programmer in every line?
My theories aren't matching reality, so I find myself interested in the why of that mismatch.
https://github.com/kisielk/errcheck
I agree that having things like errcheck and go-sumtype all wired up using gometalinter is pretty novel and only partially gross.
I'm noodling around with ideas here here, not promoting Go as this language; if it were designed for that there's probably some things it would do differently. I just find it sort of intriguing that if you don't mind using tools, a lot of the common criticisms of Go can be largely mitigated without necessarily paying the price of putting the complexity in the language itself; even if that doesn't personally appeal to you it's interesting to consider it as a deliberate design paradigm. Is this a good idea? It's almost like having a modular language where you only use the complex stuff where you really get an advantage from it but don't pay for that stuff where you don't. You couldn't use this to bodge in things like the Rust borrow checker that really needs the whole program to use it to obtain the benefits, and a lot of what Haskell does with the typechecker would be infeasible, but it's not hard to see things like "sum type completeness checking" and "generics via code templating" and even things as large as "optional typing" being feasible this way, without the core language authors having to arbitrate all these things, and without the whole community necessarily having to adopt these things to see advantages. Compare with, for instance, the rather large mess Python has become over the years by absorbing feature after feature into the core language. See also the gometalinter [1], in which the community aggregates a collection of smaller tools all written fully independently, with little-to-no coordination needed, all standalone, and then tied into what is, frankly, not a half bad language linter, especially if you play with the config a bit.
[1]: https://github.com/alecthomas/gometalinter