Records and annotations (was: Updated document on data classes and sealed types)

Brian Goetz brian.goetz at
Tue Mar 19 18:42:11 UTC 2019

> But, that still leaves the question of whether the desugaring should, or should not be, transparent to annotations.  My sense is that pushing annotations down to fields, ctor params, and accessors _seems_ friendly, but also opens a number of uncomfortable questions.  

Also, we’ve been treating these as if they are the same case.   In

    record R(@Foo int a);

I think the case for “pushing down” @Foo to the _field_ for a has a somewhat stronger argument than pushing it down to the _accessor method_ for a.  (Not only does the record component look like a field declaration, but record declarations are about “let me declare the state, and then you can derive the API from that state.”  So pushing the annotations down to the actual state declaration seems sensible, but pushing annotations from there to the corresponding API elements seems more questionable.  (Thought experiment: if we had some sort of “auto accessor” mechanism:

    Class Foo {
        @Foo with-getter with-setter int a;

Would we similarly be talking about pushing the @Foo annotation down to the synthetic methods, or would we say “Well, obviously @Foo is an annotation on the declaration of the field.”  It’s not a slam-dunk either way, but the latter seems more likely to me.  

Which is to say: there are possibly-credible middle grounds between “push it everywhere we could conceivably do so” and “it’s an annotation on the record component, full stop.”  

More information about the amber-spec-observers mailing list