question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Private Super-Trait Inconsistency with 2.13

See original GitHub issue

Compiler version

3.0.1

Minimized code

package foo

private[foo] trait Super {
  private[this] val dummy = "42"
}

trait Sub extends Super {
  def foo: Unit
}

// meanwhile, in another part of town

package bar

object Baz extends Sub {
  def foo = ()
}

Output

Scala 2.13 compiles the above just fine. In 3.0.1, this will result in an error saying that class Super cannot be accessed in module Baz.

Expectation

Consistency with 2.13.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
smartercommented, Jul 19, 2021

Quoting from the spec (https://www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#templates):

It is possible to write a list of parents that starts with a trait reference, e.g. mt_1​ with … with mt_n​. In that case the list of parents is implicitly extended to include the supertype of mt_1​ as the first parent type

In other words, when we write:

object Baz extends foo.Sub

because Sub is a trait whose parent class is Super, it gets expanded to:

object Baz extends foo.Super with Sub

which does not typecheck because foo.Super is inaccessible. So I think that the error is legitimate, and Scala 2 just happens to not check for accessibility here, so I’d say this is a bug in Scala 2 rather than Scala 3 (but this is also the option that requires the least amount of work for me, so I’m biased 😃).

0reactions
djspiewakcommented, Jul 19, 2021

which does not typecheck because foo.Super is inaccessible. So I think that the error is legitimate, and Scala 2 just happens to not check for accessibility here, so I’d say this is a bug in Scala 2 rather than Scala 3 (but this is also the option that requires the least amount of work for me, so I’m biased 😃).

Sounds good to me!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Private supertrait pattern #16 - rust-lang/api-guidelines - GitHub
This pattern is a way to retain the ability to add/remove/modify methods of a public trait without breaking compatibility.
Read more >
Higher-Kinded Types in Dotty - Scala 3
The definition of Lambda$NP shows that Lambda traits form a subtyping hierarchy: Traits which have covariant or contravariant type parameters are subtypes of ......
Read more >
Private Methods on a Public Trait - Jack Wrenn
The first two approaches are well-established in the Rust community, but the third might be relatively novel. Approach 1: Private Super-Trait.
Read more >
Better Implicit Search Errors: problematic cases wanted!
Avoid relying on private dependencies. Avoid depending on macros (e.g., replace macros by dummy code with the same signature, ...
Read more >
Personality Assessment in the Workplace - CiteSeerX
interpersonal relations, which involve considerable personal evaluation from ... assesses five supertraits and 20 subtraits that are based on the Big Five.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found