[records] updates for Preview 6. Default access modes

[Tagir Valeev]

I don't like B. The problem with B is that having a public default you
may mistakenly expose an implementation detail, and it could be hard
to fix this when clients start to use it. With interface methods this
is less important, because if you have an implementation inside
interface, you should explicitly mark it with either 'default'
(meaning that it's still part of an interface) or 'private' (meaning
that it's an implementation detail). But specifying an interface
method with a body without a modifier at all is an error, so you will
have to think. Records are not of this kind. They are not abstract,
every method has an implementation, and it's perfectly valid to add a
method without specifying any modifier. You will have all the tests
passing, etc., but you're still doing a mistake, which is expensive to
fix.

Of these options, I like C the most, though I would modify it:
D. The access modifier for explicit overloads to synthetic members
(canonical constructor & accessors) must be the same or more
permissive than an access modifier for the record itself. The absence
of access modifier means 'package-private', as usual for classes. This
would require 'public' for public records, and it's nice because you
will see that it's really a part of the API. On the other hand, this
would reduce noise for inner/local records where you can omit the
access modifier. And still, you can specify public on local records,
so you can easily reduce the record visibility without the need to
modify all the members.

Adding an explicit package/non-public modifier is a good idea per se,
but it's orthogonal to the records case. We can implement it (allowing
package-private members in interfaces), yet stick with my D proposal.

With best regards,
Tagir Valeev.

On Fri, Jan 10, 2020 at 1:52 PM John Rose <john.r.rose at oracle.com> wrote:
>
> P.S.  The alert reader has perhaps already said, “but wait, if you
> make records like interfaces, then records cannot define non-public
> APIs!”  Very good, alert reader, that’s just like interfaces.  And we
> can amend *both* by adding some way to overcome the default
> “public” with a new modifier that means “I know you default to
> public, and I know the normal syntax for package access is to
> say nothing and obtain a different default, and I want that package
> access, please.”  Potential spellings for that modifier are “package”
> and “non-public”.
>
> In interfaces, haven’t you ever wanted to define a non-public nested
> class which implements the interface or carries some other interesting
> implementation data?  The JVM has no objection to you doing so, but
> the language does.  It would be helpful to allow an interface to define
> a non-public nested class, for the sake of modularity.  The “package”
> or “non-public” modifier would support this.
>
> Even for garden variety classes there’s a use case for such a modifier.
> Haven’t you ever wanted to mark an API point, “don’t make this public,
> for heaven’s sake”?  I use the comment “/*non-public*/” which drives
> maintainers crazy.  Saying “non-public” or “package” would be a better
> way to document the intention.
>