Skip to content

private-ness of trait constructor ignored #17089

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pweisenburger opened this issue Mar 11, 2023 · 4 comments · Fixed by #17094
Closed

private-ness of trait constructor ignored #17089

pweisenburger opened this issue Mar 11, 2023 · 4 comments · Fixed by #17094
Milestone

Comments

@pweisenburger
Copy link
Contributor

Compiler version

3.3.0-RC3

Minimized code

object o:
  trait T private[o]()

def test = new o.T { }

Output

The code compiles. I would expect it not to. My expectation was that trait T private[o]() scopes the constructor of T private in o (but maybe this is not the case?). I assume that the anonymous class created in new o.T { } calls the T's constructor. If that is the case, then I think creating instances of T should only be possible within o (which was the intention here).

@pweisenburger pweisenburger added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 11, 2023
@som-snytt
Copy link
Contributor

object o:
  trait T private[o]()
  trait U private[o] (i: Int)

def test = new o.T { }
def ouest = new o.U(42) { }

class C extends o.T
class D extends o.U(42) // constructor U cannot be accessed as a member of o.U from class D.

Error as expected with parameters.

@odersky
Copy link
Contributor

odersky commented Mar 12, 2023

@som-snytt Yes, that's the point here. We don't call the constructor of a trait unless we have to pass parameters. So declaring it as private[o] does not help.

@odersky odersky closed this as completed Mar 12, 2023
@pweisenburger
Copy link
Contributor Author

Makes sense that the constructor is not called if there are no parameters to pass. But this sounds more like an optimization that should not affect the surface language. I find it a bit concerning that trait T private[o](...) behaves differently depending on whether the argument list is empty or not, in particular that the private modifier is sometimes silently ignored by the compiler.

If the code is legal, private should not be a no-op IMO. Thus, I believe the compiler should issue a warning or even reject the program, or – as a much more useful semantics – private should prevent instances of the trait from being created/mixed-in out of scope (to this end, the compiler could check that the constructor is accessible, regardless of whether it is actually called or not).

Also, the statements in the trait's body are executed during construction (either as part of the constructor or of some special mixin initialization method). I think a reasonable expectation is that private[o] makes construction private.

@odersky odersky reopened this Mar 12, 2023
@odersky
Copy link
Contributor

odersky commented Mar 12, 2023

I agree this warrants further investigation.

@odersky odersky removed the stat:needs triage Every issue needs to have an "area" and "itype" label label Mar 12, 2023
odersky added a commit to dotty-staging/dotty that referenced this issue Mar 12, 2023
This allows to restrict inheritance of traits even if the constructor is not
called, or not called at Typer.

Fixes scala#17089
nicolasstucki added a commit that referenced this issue Mar 23, 2023
…#17094)

This allows to restrict inheritance of traits even if the constructor is
not called, or not called at Typer.

Fixes #17089
Dedelweiss pushed a commit to Dedelweiss/dotty that referenced this issue Apr 17, 2023
This allows to restrict inheritance of traits even if the constructor is not
called, or not called at Typer.

Fixes scala#17089
@Kordyjan Kordyjan added this to the 3.3.1 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants