[records] customized accessor returning subtype

[Maurizio Cimadamore]

On 10/12/2019 00:36, Alex Buckley wrote:
> I'm glad this was asked and answered during CSR, but I think Dmitry is 
> clear about WHAT the spec says. I believe he is asking WHY an explicit 
> accessor's return type must be identical to the component's type.
>
> At the heart of the matter is the fact that a Number-typed component 
> implies a Number-typed field. Code in an accessor with an Integer 
> return type would have to downcast the field often, or at least 
> sometimes. Everything about that accessor makes it harder to 
> understand the state of the record *which was meant to be plain from 
> the Number component*. Does the "true" state involve a Number or an 
> Integer, and does it depend on other conditions, and when, and why? A 
> covariant override is for when a subclass adds specialization, but 
> there's no specialization to be gained within a record.
>
Not to mention the fact that, as soon as you go down that path 
(covariant accessors) some developers could ask for the dual 
(contravariant constructor parameters) - at which point I think we're 
well past the design center for records.

Maurizio

> Alex
>
> On 12/9/2019 4:04 PM, Joe Darcy wrote:
>> FYI, this issue was raised in the CSR review:
>>
>>> In "An implicitly declared public accessor method with the same name 
>>> as the record component, whose return type is the declared type of 
>>> the record component, unless a public method with the same signature 
>>> is explicitly declared in the body of the declaration of R."
>>>
>>> does that imply a "covariant override" accessor can be explicitly 
>>> defined as the signature does not include the return type? For 
>>> example if the component had a type of Object and the user defined 
>>> an accesssor method with a type of String? Would a bridge method 
>>> need to be defined? Should the return type be constrained to match too?
>>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8233433?focusedCommentId=14302123&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302123 
>>
>>
>> and replied to
>>
>>> This is a very good question. I've actually changed the description 
>>> of accessor methods and constructor methods to make this clearer (I 
>>> hope). In essence there is a two stage process. For accessor 
>>> methods: If you have the name of a component and an empty formal 
>>> parameter list, then you are considered to be an accessor method for 
>>> the component. We then ask additional criteria of you - it's a 
>>> compile-time error if you don't satisfy them! This includes having a 
>>> return type that is identical to the derived type of the record 
>>> component, being |public|, etc. It's essentially the same for 
>>> constructors: a record component list essentially derives a 
>>> canonical constructor signature. If you are a constructor that is 
>>> override-equivalent, then you are a canonical constructor. We then 
>>> ask additional criteria of you, being |public|, not being generic, etc.
>>>
>>> These definitions clear up a lot of corner cases, and more 
>>> importantly lead to better error messages. (In your particular 
>>> example, the |String| returning method would /not/ be an accessor 
>>> for the |Object| component, so one would be implicitly declared for 
>>> you, and then you'd get an error as we'd have two overloads with 
>>> identical signatures).
>>>
>> https://bugs.openjdk.java.net/browse/JDK-8233433?focusedCommentId=14302457&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302457 
>>
>>
>> Cheers,
>>
>> -Joe
>>
>> On 12/9/2019 11:09 AM, Dmitry Bessonov wrote:
>>> Is there any reason for not allowing a customized accessor to return 
>>> rc subtype:
>>>
>>> record R(Number number) {
>>>      public Integer number() {
>>>          return 42;
>>>      }
>>> }
>>>
>>> Error: java: invalid accessor method in record R
>>>    (return type of accessor method number() is not compatible with 
>>> type of record component number)
>>>
>>>
>>> dmitry
>>>