Infer private[this]

[odersky]

Infer private[this] if all accesses are via this, even if it is not explicitly specified.

Deprecate usage of private[this] and protected[this] under -strict (i.e. for 3.1.).

The main reasons for dropping private[this] are:

• it is syntactically an irregular case. A pair of brackets usually encloses a type, but this is a value.
• its effect over private is purely local and can be easily inferred
• it leads to bike shedding: should I use private or private[this]? One is shorter but the other might be more efficient.

protected[this] by now influences compiler decisions in no way at all. Its delta over protected is small. protected by itself is niche (e.g. Don Syme has argued eloquently why it is too niche for F#), so having two variants of it looks like overkill.

[odersky]

test performance please

[dotty-bot]

performance test scheduled: 1 job(s) in queue, 0 running.

[dotty-bot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/7411/ to see the changes.

Benchmarks is based on merging with master (0f7a85b)

[pshirshov]

While I welcome removal of this syntax, I don't thin that the semantic is unneccessary. It's very convenient to be able to enforce stricter rules. Also I wouldn't call protected modifier a niche thing - more access control is always better.

To be quiet honest I think we need lot more flexible access restriction system, so we may specifiy complex predicates on who may and may not access an entity.

Could you consider keeping the functionality under different syntax please?.. Maybe not a modifer but an annotation?..

[odersky]

Maybe not a modifer but an annotation?..

That's just a cop out. Seriously, I have not seen a convincing argument why distinctions between private/protected and private/protected[this] are necessary. And unnecessary distinctions just lead to bikeshedding and complexity.

One could argue that the default is wrong and it should always be [this]. We already had this discussion, and I believe that the reasons for keeping plain private and protected were convincing, for algorithmic reasons as well as backwards compatibility.

[neko-kai]

@odersky
protected[this] and [this] access modifiers in general are required for variance in path-dependent types, e.g.

trait ProtectedThisVarianceOk[-A, +B] {
  protected[this] type AliasA = A
  protected[this] type AliasB = B
}

trait ProtectedVarianceIsNotOk[-A, +B] {
  // Error:(16, 18) contravariant type A occurs in invariant position in type A of type AliasA
  //  protected type AliasA = A
  protected type AliasA = A
  protected type AliasB = B
}

Scala 2 allows declaration of AliasA because it's not a visible type member of ProtectedThisVarianceOk – as an internal-only alias its aliasing of contravariant A cannot break the type's outer visible variance.

IMHO removing protected[this] means fundamentally gimping path-dependency.

[odersky]

Treating protected[this] specially for variance is unfortunately unsound (scala/bug#7093). Nothing changes for private[this]; the [this] is simply inferred.

[neko-kai]

Sorry, I was not aware. It still feels like a bad blow for cake & PDT; possibly less dramatic if variant aliases are out of the picture anyway... Removal of private[this] is of course strictly an improvement (if someone needs a not-this private for reflective field access, they can use private[MyClass] for the same effect)

[ryanberckmans]

Here is a proposal to retain private[this] in Scala 3.