The current fixed-point logic in cmd/gg is based on the following original "requirement": that the outputs of one generator can act as inputs to another generator in the same package. It does come at a cost, however:
each directive in a given package is run at least twice
gg has a more complex implementation
The first cost is almost complete mitigated by the gg cache (except where you are making changes the development cycle can be slowed in some situations). The second cost remains.
Firstly, it's worth considering whether this is even a valid "requirement". The problem can, to a certain extent, be side-stepped by adapting one of the mutually dependent generators to know about the other, in effect reducing two directives (n in the general case) down to one. This would in effect leave you in a situation where for a given package, no two directives are mutually dependent.
However this doesn't guarantee that you will never encounter a situation of mutual dependence. The fixed-point logic acts as a good back stop in this respect.
As @rogpeppe observed, an argument against this (overly-)defensive approach is that some generators may be non-deterministic (unintentionally of course). This point is largely mitigated by having a CI run:
remove all generated files
re-run gg
check there is zero git diff (or equivalent)
If the fixed-point logic were removed, you could still end up with zero git diff. But this would offer no guarantee you wouldn't generate a diff the second time around, i.e. by re-running gg.
The current fixed-point logic in
cmd/ggis based on the following original "requirement": that the outputs of one generator can act as inputs to another generator in the same package. It does come at a cost, however:gghas a more complex implementationThe first cost is almost complete mitigated by the
ggcache (except where you are making changes the development cycle can be slowed in some situations). The second cost remains.Firstly, it's worth considering whether this is even a valid "requirement". The problem can, to a certain extent, be side-stepped by adapting one of the mutually dependent generators to know about the other, in effect reducing two directives (
nin the general case) down to one. This would in effect leave you in a situation where for a given package, no two directives are mutually dependent.However this doesn't guarantee that you will never encounter a situation of mutual dependence. The fixed-point logic acts as a good back stop in this respect.
As @rogpeppe observed, an argument against this (overly-)defensive approach is that some generators may be non-deterministic (unintentionally of course). This point is largely mitigated by having a CI run:
gggit diff(or equivalent)If the fixed-point logic were removed, you could still end up with zero
git diff. But this would offer no guarantee you wouldn't generate a diff the second time around, i.e. by re-runninggg.Plenty of food for thought.