mnemnion
commented
4 months ago I don't think this is a good general feature for a code quality tool.
Looking through the list of what Aqua tests, everything is a real problem, latent or otherwise. Using a non-public part of someone else's package is a hypothetical problem: some future minor release might break that feature. Or that might not ever happen.
When I use internals, which does happen, I write a test which verifies the behavior I need from that function. This means if an upgrade breaks what I rely on, the test suite will tell me right away, and I can decide what to do about it.
This isn't naughty behavior (type piracy) a lurking problem (method ambiguity, compat boundaries), or a mistake (undefined exports). It's just using code, and that code has the same guarantees as the (many!) packages which aren't 1.0: none. I don't need Aqua shaking its finger at me over it.
Sure, I could turn it off, and would. But this gets public entirely backward. It's a self-imposed obligation of consistent behavior for some part of a package. It doesn't mean "hands off unless I say so".
See this comment on Discourse:
Sounds like a job for Aqua? Not urgent of course but opening the issue to keep track