On 8/14/20 1:18 PM, Brian Goetz wrote:
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.
It wouldn't help the reliability issue at all, but an interesting
enhancement to the javac option would be to enable MP for the exported
API of a module, and not otherwise.
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?
