Can we please reach some kind of decision on access

[scabug]

I've tried for years to obtain some clarity here. It is a large tax on users and compiler developers alike that even if people knew and understood what is supposed to work and how it's supposed to work with respect to the 16 permutations of qualified/object private/protected type/value visibility/access - which they don't, myself included - that knowledge would be of limited use because there are so many bugs.

The bugs persist in large part because I lack sufficient information to fix them. It would be wonderful if we could make some forward progress on this somehow. This is a small sample of the set of behaviors which are hard to explain or defend (although I admit to the possibility that all of this is "as specified" since as I said, I am incapable of deriving the intended behavior from the specification.)

trait FB[T <: FB[T]] { }

package foo {
  class Bippy {
    private[Bippy] class FB1 extends FB[FB1]
    private[foo] class FB2 extends FB[FB2]
    protected[this] class FB3 extends FB[FB3]
    protected class FB4 extends FB[FB4]

    def f1 = new FB1
    def f2 = new FB2
    def f3 = new FB3
    def f4 = new FB4
  }
}

/****

scala> val x = new foo.Bippy
x: foo.Bippy = foo.Bippy@62b6772

scala> x.f1
res0: x.FB1 = foo.Bippy$FB1@4bfd366a

scala> x.f2
res1: x.FB2 = foo.Bippy$FB2@16fc39cd

scala> x.f3
res2: x.FB3 = foo.Bippy$FB3@d72f8f7

scala> x.f4
res3: x.FB4 = foo.Bippy$FB4@104a73cb

scala> var y: x.FB1 = _
<console>:8: error: class FB1 in class Bippy cannot be accessed in foo.Bippy
       var y: x.FB1 = _
                ^

scala> var y: x.FB2 = _
<console>:8: error: class FB2 in class Bippy cannot be accessed in foo.Bippy
       var y: x.FB2 = _
                ^

scala> var y: x.FB3 = _
<console>:8: error: type FB3 is not a member of foo.Bippy
       var y: x.FB3 = _
                ^

scala> var y: x.FB4 = _
<console>:8: error: class FB4 in class Bippy cannot be accessed in foo.Bippy
 Access to protected class FB4 not permitted because
 enclosing object $iw is not a subclass of
 class Bippy in package foo where target is defined
       var y: x.FB4 = _
                ^

After all that, god forbid we let 'private class FB5' escape...

scala> private class FB5 ; def f5 = new FB5
<console>:7: error: private class FB5 escapes its defining scope as part of type FB5
       private class FB5 ; def f5 = new FB5
                               ^

***/

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-6794?orig=1
Reporter: @paulp
See #1352, #5114, #1409, #1415, #1469, #1800, #1915, #2568, #4316, #4323, #4400, #4549, #4626, #4739, #4962, #5000, #6165, #6213, #6232, #6437, #6617, #6760, #6880, #4845, #5508, #6245, #1994, #3144, #3167, #3276, #3946, #4218, #5134, #5217, #5251, #5565, #5665, #6216, #6309, #6585, #6733, #6793, #6003, #5008, #3197, #4548, #2840
Blocks #1994

[scabug]

@retronym said:
That's some thorough linkin'!

[scabug]

@paulp said:
It's a lot less than I could have done. I mostly left out some strongly related subjects like name mangling (much of the complexity of which arises from the access scheme), super/trait/protected accessors, etc. But this much should offer a taste.

[scabug]

Mike Slinn (mslinn) said:
Will this issue be resolved for 2.11 release?

[scabug]

@retronym said:
This is a meta-bug, it isn't going to be solved in one hit. The change in 'fix-by' version was part of a bulk change.

[scabug]

Mike Slinn (mslinn) said:
Jason, not sure what the conclusion is. The bug is currently unassigned. Will there be any improvement in the area described by this bug report for 2.11? ... Thanks!

[scabug]

@retronym said:
Mike: we are wrapping up 2.11 and don't plan to make changes related to access at this late stage in the cycle.

[scabug]

Mike Slinn (mslinn) said:
That is unfortunate. I am ready to rerecord a lecture for http://scalacourses.com which discusses this visibility. Earlier versions of the lecture referenced 2.11M5 as being the point at which access visibility would achieve greater clarity, then 2.11M7. Instead, I will have to continue to say that this remains poorly defined and recommend that the undefined modifiers should be avoided.

Might it still be possible to enhance the documentation to state which modifiers that actually work as per spec, and inform the reader that the other possibilities are undefined? Here are the 8 possibilities I am referring to: protected, protected[packageName], protected[className], protected[this], private, private[packageName], private[className] and private[this].