A peek at the roadmap for pattern matching and more

[Jonathan Gibbons]

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