The implementation was merged into Dotty.

why can't we have static as a keyword?

Because adding new keywords breaks existing code that used them as identifiers. Adding keywords must be donevery sparingly, only when there is no other option.

I guess libs doing interop with Java code will be avoiding that.

@DarkDimius is there any change you want to do here before the SIP review?

I guess libs doing interop with Java code will be avoiding that.

Why would they? You may want some data to be seen as Java static field, and you can use@static for this.

@DarkDimius is there any change you want to do here before the SIP review?

@jvican, I've applied those changes now and cleared git history. Feel free to merge if it looks good.

Great changes, let's merge it for next week's discussion.

#635

• I don't think it's a good idea to let code gen depend in non-obvious ways on an annotation. Can we break this down further? How about....
  • Always emit object members as class statics, as suggested by Martin (solves initialization mismatch that killedImplement @static annotation on singleton object fields. scala#894, and keeps static members out of class, which would be problematic in our type system)
  • Deal with name clashes using an@exportedName annotation?
  • Allow emitting apublic static field without accessor using@suppressAccessors?

The proposal should go into more detail on:

• What about binary compat (adding/removing@static annotation)
• Interaction with initialization semantics?

Some relevant bugs:

• https://issues.scala-lang.org/browse/SI-6189
• https://issues.scala-lang.org/browse/SI-6294
• https://issues.scala-lang.org/browse/SI-6236

I'd like to see the "Compilation scheme" section fleshed out. Currently, it talks about how this would fit into the compiler pipeline, but lacks details about how things would be compiled to bytecode.

Here's an example I'm interested in:

packagep1;objectC {@staticvalfoo:AnyRef=C;valbar:AnyRef=C }

If I translate this according to the intuitive description herein, taking a few guesses at the details, I start with:

publicclassTest {publicstaticvoidmain(String[]args) {System.out.println(C$.MODULE$.foo());// null  }}classC {publicstaticfinalObjectfoo;static {foo =C$.MODULE$;// initializer moved to CompanionClass.<clinit>  }}finalclassC$ {publicstaticC$MODULE$;privatefinalObjectbar;publicstaticObjectfoo() {returnC.foo; }static {Objectx =C.foo;// or UNSAFE.ensureClassInitialized(classOf[C])newC$();  }privateC$() {super();MODULE$ =this;bar =this;  }}

Running this printsnull. I guess we should move the call toC.<init> after the super constructor call and the assignment of the module var:

finalclassC$ {publicstaticC$MODULE$;privatefinalObjectbar;publicstaticObjectfoo() {returnC.foo; }static {newC$();  }privateC$() {super();MODULE$ =this;Objectx =C.foo;// or UNSAFE.ensureClassInitialized(classOf[C])bar =this;  }}

Which avoids the NPE.

But in that case, triggeringC.<clinit> beforeC$.<clinit> would reverse the order that the initalizer forfoo and the super constructor of the module class is run.

Both of these variations have another drawback: References toC in the RHS of static initializers introduce a cyclic dependency betweenC.<clinit> andC$.<clinit>. This is deadlock prone if a a pair of threads simultaneously statically initialize the class and module class.

So maybe we instead should put leave all the initalization code in the module class?

classC {publicstaticObjectfoo;// can't be final}finalclassC$ {publicstaticC$MODULE$;privatefinalObjectbar;publicstaticObjectfoo() {returnC.foo; }static {newC$();  }privateC$() {super();MODULE$ =this;C.foo =this;bar =this;  }}

This looks more promising for thread-safe initialization, and preserving semantics. But we are no unable to declarefoo as final, which is a bit of a drag, because one reason you want to make a field static is to hold a method handle "constant", and hotspot only is able to fully inline invocations through that handle if the field is markedfinal. (Or, if it has the JDK internal annotation,java.lang.invoke.Stable, which isn't in our box of tricks.)

We could also consider omitting the accessor methods for@static fields and emitting direct accesses to the field.

classC {publicstaticObjectfoo;static {foo =C$.MODULE$;  }}finalclassC$ {publicstaticC$MODULE$;privatefinalObjectbar;publicstaticObjectfoo() {returnC.foo; }static {newC$();  }privateC$() {super();MODULE$ =this;Objectx =C.foo;// or UNSAFE.ensureClassInitialized(classOf[C])bar =this;  }}

Is the proposed desugaring.

@retronym

I guess we should move the call toC.<init> after the super constructor call and the assignment of the module var:

I guess you've meantC.<clinit>. Than that's true.

But in that case, triggeringC.<clinit> beforeC$.<clinit> would reverse the order that the initalizer for foo and the super constructor of the module class is run.

C$.<clinit> isn't user defined. Did you meanC$.<init>?

In case you did, the order in which initializer for foo and the super constructor of the module class is run indeed may change under the proposed sip. It's discussed herehttps://github.com/scala/scala.github.com/pull/658/files#diff-9284321b7900073f358a16a971c06881R159 , do you want me to expand this discussion?

This is deadlock prone if a a pair of threads simultaneously statically initialize the class and module class.

If we always trigger initialization ofC.<clinit> fromC$.<init> we will introduce ordering here that should help. But in case user-code inherently has cycles in inititaliziation, I don't think we can do anything.

Thanks for the questions, I'll expand the "Compilation scheme" section.

do you want me to expand this discussion?

Yes, it would be useful to talk about the super constructor thing explicitly,
perhaps with an example showing how the order could vary depending on how
whether the class or module was initialized first.

If we always trigger initialization of C. from C$. we will
introduce ordering here that should help. But in case user-code inherently
has cycles in inititaliziation, I don't think we can do anything.

I still think that we're introducing a new form of cycle by moving
the code into 'C$'-s static initializer, but I guess that's what the user
is asking for with this annotation, so we can argue that it is the user's
responsibility to code around this possibility.