I was actually thinking of the most common use-case of the predict method - determining the address before actual deployment. I guess emitting event doesn't help in that case? Off-chain computation works great too!
Going off on a tangent, I was wondering why the library offers the predict method on-chain, since there are such cheaper alternatives. Having it in the library would make teams implement it on, which otherwise could've saved them gas? What's the reasoning behind having it in the library?
Sometimes you definitely need the predict method on chain.
For example, for Forta Network we implemented a feature where unvested tokens held in a VestingWallet on Ethereum could be bridged over to Polygon to participate in staking, but couldn't be used for anything else. The way this was implemented was by creating a Create2 factory of special-purpose wallets on Polygon that could only perform staking actions. The VestingWallet contracts on Ethereum would predict the location of that wallet based on the Create2 logic and bridge the funds to it directly.
Do you think any of our documentation is misleading users to think that they need to do have the predict method on chain?
I haven't noticed anything mentioned in the docs specifically talking about exposing Clones.predictDeterministicAddress(). But I think many devs would think thats required or a standard to expose it. Most contracts that I've seen make use of Clones also expose the method.
So nothing misleading in the docs, but probably missing a mention of its usage