Inner traits are sometimes thought to be SAM types when they aren't

[smarter]

The following code:

class Outer {
  trait Inner {
    def apply(x: Int): Int
  }
  val f: Inner = x => x
}

Becomes after frontend:

package <empty> {
  class Outer() extends Object() { 
    <trait> trait Inner() extends Object { 
      def apply(x: Int): Int
    }
    val f: Outer.this.Inner = {
      def $anonfun(x: Int): Int = x
      closure($anonfun:Outer.this.Inner)
    }
  }

So far so good: Inner is a SAM type (also known as a Functional Interface) so it can be the result of a closure, now watch what happens after ExplicitOuter:

class Outer() extends Object() { 
  <trait> trait Inner() extends Object() { 
    def apply(x: Int): Int
    final def Outer$Inner$$$outer: Outer
  }
...

Oh no! Inner now has two abstract methods, it's no longer a SAM type, and that's terrible.

I'm not sure but I think that there are two things wrong here:

• The SAMType extractor should not consider traits that may get an outer pointer as SAM types, not sure what the best way to ensure that is.
• In this example, it seems like Inner should have the flag PureInterface set, that way it won't get an outer pointer. I investigated a bit: NormalizeFlags should set PureInterface if NoInits is set but that flag isn't set on Inner either. Namer#denotsNamed should set NoInits, but it doesn't because TreeInfo#isNoInitMember returns false when called on the apply DefDef. That's where I stopped.

@odersky : Could you take a look at this and advise on the best way to fix it?

[retronym]

/cc @adriaanm

[DarkDimius]

Actually with a bit of patching such trait could become a SAM:

  <trait> trait Inner() extends Object() { 
    def sam: Pair[Function1[Int, Int], Function0[Outer]]
    def apply(x: Int): Int  = sam._1.apply(x)
    final def Outer$Inner$$$outer: Outer = sam._2.apply()
  }

Thought I'm pretty sure this will lead to performance degradation.

[adriaanm]

We dodge this as follows (edited for brevity, see comment):

$ scalac -Xexperimental /Users/adriaan/Desktop/bugs/sam_outer.scala -Xprint:expl

[[syntax trees at end of             explicitouter]] // sam_outer.scala
package <empty> {
  class Outer extends Object {
    def <init>(): Outer = { Outer.super.<init>(); () }
    abstract trait Inner extends Object { def apply(x: Int): Int }
    private[this] val f: Outer.this.Inner = {
      def apply$body(x: Int): Int = x;
      final class $anonfun extends Object with Outer.this.Inner with Serializable {
// outer passed in to constructor, stored in field
        def <init>($outer: Outer.this.type): <$anon: Outer.this.Inner> = { $anonfun.super.<init>(); () };
        final override def apply(x: Int): Int = apply$body(x);
        private[this] val $outer: Outer.this.type = _;
        def $outer(): Outer.this.type = $anonfun.this.$outer
      };
      new <$anon: Outer.this.Inner>(Outer.this)
    };
    def f(): Outer.this.Inner = Outer.this.f
  }
}

[smarter]

@adriaanm : Does that mean you create an anonymous class instead of using LambdaMetafactory? If not, how does this get translated into something that LambdaMetafactory can use?

[DarkDimius]

@adriaanm, what you are proposing isn't a SAM. SAM's cannot have fields or constructors.
Thats a good-old anonymous class.

[DarkDimius]

My opinion on the issue: only static traits should be considered as potential SAM's.

[retronym]

The terminology is a bit confusing here. In Scalac, we take SAM to broadly mean a type that can be instantiated, at typer phase, in the form new T { def m[tparams](paramss) = body }. If T ends up as a Functional Interface, the backend would be free to defer synthesis of the anonymous class to LambdaMetafactory. But if needed, we can create an anonymous class eagerly.

[retronym]

Being a static trait is not sufficient; traits with fields or with super accessors require Scala to perform some work in mixin. @lrytz investigated how variants of traits could be encoded with defaults in https://github.com/lrytz/traits-default-methods/commits/master

[adriaanm]

Right, I was thinking of the wrong Sammy. Thinking out loud some more on the metro home: can we lower the outer pointer to be part of the environment captured for the lambda?

[DarkDimius]

@adriaanm I've shown how outer pointer could become part of environment, see my first comment in this issue. Unfortunately it will come with performance penalty for every invocation.