SI-7859 Value classes may wrap a non-public member #2965
Conversation
ghost
assigned 
|
Updating the documentation: scala/docs.scala-lang#250 |
|
I must say that I'm not entirely happy with increased use of The problem with
I'd vastly prefer if we followed what I mention this only because I'm uneasy to see yet another use of suboptimal (in my opinion) mechanism. I'll review this PR on Monday or Tuesday. |
|
Just to link things together, here's @gkossakowski's ticket proposing a more Java-esque approach to access: https://issues.scala-lang.org/browse/SI-7085 |
|
@retronym: thanks, I totally forgot that this is being tracked in JIRA. I must develop the habit of searching JIRA before I repeat myself again. |
|
PLS SYNC |
|
Just spotted the test failures. Will investigate. |
We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.
This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.
This commit:
- refactors the code that enforced the restrictions, improving
a few error messages and positions. The remaining restrictions
needed some rewording in light of this change.
- allows value classes to have non-public, val parameters.
private[this] / protected[this] are still disallowed as value
classes don't have a concept of `this`, and because trying to
accomdate then would complicate the implementation.
This means that `class C(x: Int) extends AnyVal` is not allowed,
the user still must write `private val x: Int` or `val x: Int`.
- Outlaw `class C()()(val x: Int) extends AnyVal` to curtail any
bugs that might lurk in such a formulation.
The tests:
- Show that the privacy is respected in the typer phase, under
joint and separate compilation. We don't want a repeat performance
of SI-6601.
- Show that code that needs compiler-generated unboxes works under
both compilation scenarios
- Checks that the remaining restrictions are enforced and well
communicated.
|
Pushed an updated check file. |
|
ping @gkossakowski |
|
LGTM. |
SI-7859 Value classes may wrap a non-public member
We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.
This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.
This commit:
refactors the code that enforced the restrictions, improving
a few error messages and positions. The remaining restrictions
needed some rewording in light of this change.
allows value classes to have non-public, val parameters.
private[this] / protected[this] are still disallowed as value
classes don't have a concept of
this, and because trying toaccomdate then would complicate the implementation.
This means that
class C(x: Int) extends AnyValis not allowed,the user still must write
private val x: Intorval x: Int.Outlaw
class C()()(val x: Int) extends AnyValto curtail anybugs that might lurk in such a formulation.
The tests:
joint and separate compilation. We don't want a repeat performance
of SI-6601.
both compilation scenarios
communicated.
Review by @gkossakowski