A peek at the roadmap for pattern matching and more

[Brian Goetz]

>
> 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?