Backend ignores NoInits flag, always emit $init$ method on traits

[smarter]

trait Foo {
  def meth(x: Int): Int
}

Compiled with dotty, then decompiled with cfr:

public interface Foo {
    default public void $init$() {
    }

    public int meth(int var1);
}

Compiled with Scala 2.12 then decompiled:

public interface Foo {
    public int meth(int var1);
}

[DarkDimius]

This is not a backend issue, this is due to mixin.

[smarter]

Could you give some details?

[DarkDimius]

@smarter, if you run the example you've posted with -Xprint:all, you'll see that $init$ method is created in
TreeTransform:{elimErasedValueType, vcElideAllocations, mixin, LazyVals, memoize, linkScala2ImplClasses, nonLocalReturns, capturedVars, constructors, functionalInterfaces, getClass}

Generally, in dotty the backend is very dumb. I've tried to move all logic away from it to parts of pipeline that are Y-checked.

[DarkDimius]

I actually think that the current behavior is correct.
Otherwise adding a statement in a trait body would be binary incompatible.
Note that in Scala 2.12 you should also decompile implementation $class.

[smarter]

In both dotty and Scala 2.12 there are no implementation classes.

[DarkDimius]

In both dotty and Scala 2.12 there are no implementation classes.

apparently for Scala 2.12 adding adding\removing statements in a trait body is binary incompatible.
I'd prefer to be more conservative in this case. Empty static method is very small and is optimizable away by VM, but it provides stronger binary compatibility guarantees.

[smarter]

@retronym Is the presence/absence of $init$ in traits and its effect on binary compatibility something that was considered during the development of 2.12?

[odersky]

@DarkDimius I don't think we should let our design decisions be influenced by binary compatibility at this stage. I still bet on Tasty to fix that.

[DarkDimius]

@odersky could we discuss this on the next dotty meeting?
The problem here is that it's not a compiler cross-version incompatibility that Tasty may fix.
It's real bytecode incompatibility as in NoSuchMethodException, unless the mainline compiler will be able to recompile classes in runtime.

[retronym]

Related: scala/scala-dev#191

[retronym]

I tend to think we should always emit the trait constructor unless the trait is marked with @FunctionalInterface or a similar annotation to restrict what features of traits are allowed (which in turn enables better interop with Java).

[retronym]

I've also considered indirecting calls to $init$ through an invokedynamic boostrap that turns into a no-op if that method no longer exists, ie, if the inherited trait changed from being a regular trait to a functional interface (without that method). This is of couse just a limited version of what a more general binary compatibilty repair tool could do.

[DarkDimius]

I've also considered indirecting calls to $init$ through an invokedynamic boostrap that turns into a no-op if that method no longer exists, ie, if the inherited trait changed from being a regular trait to a functional interface (without that method). This is of couse just a limited version of what a more general binary compatibilty repair tool could do.

Could you please elaborate why this is better than a call to an empty static method?