I’m a bit split on this, because:
- Even since its inception 8 years ago,
.functorwas marked internal and never documented as a stable interface anywhere. (Edit: Well,mkOption { functor }is, buttype.*.functorisn’t). - However it’s true that it provides access to data that’s not otherwise accessible, so it should be no surprise that users start relying on it.
The meta question is: If an interface is truly internal but accessible, how do you discourage its use and encourage creation of stable interfaces instead? I can only imagine these, best together:
- Not documenting the interface in user docs (the case for
functor). - Prefix the interface with
_internal(not the case forfunctor), so that you can see that it’s internal at every use site.
I’ve opened lib: Document stability guarantee by infinisil · Pull Request #322733 · NixOS/nixpkgs · GitHub before to try establish the stability guarantees of lib, and perhaps it should be amended with something like the above before proceeding.
I’m tending to err on the side of stability (in line with our values), so I’m also tending towards reverting this PR, especially because you’re already the second user to report a breakage (and I always estimate an order of magnitude more people running into the same problem that we don’t hear from).
There are ways of not breaking anything, they’re just more involved and will come with (soft) deprecation of .functor entirely.