Inside Google we have enabled the `-parameters` attribute by default
and have an Error Prone check that simulates named parameters
(https://errorprone.info/bugpattern/ParameterName).
Initially we had it enabled as a compilation error. We believed that
renames of parameters happened infrequently and rarely crossed
compilation boundaries. We found that those renames were more
frequent than expected, and there were a number of accidental breaking
changes to core libraries like Guava that caused breakage at a
distance. We ended up demoting the check to a warning. The general
feeling was that this was mostly a problem for core libraries and not
typical application code. One proposal was to leave it as an error by
default, but to allow core libraries to opt out of publishing their
parameter names.
All that said, I don't think this is a problem for records since the
names there are clearly part of the API.
Thanks for enhancing the theoretical discussion with actual data!
The part of this that really interests me is the "boundary-crossing"
one. Within a maintenance boundary (package, module, multi-module
project, monorepo, depending on your tooling) you are free to rename at
will, using suitable refactoring tools, since you can find all the
clients and fix them. It only becomes a real problem when references
cross boundaries.
I'm curious what's behind your intuition about why records would be
immune (not that I disagree.) Is it that they are right there in the
header? That they are so restricted that users can't lose sight of the
fact that they are special?
