Imported From: https://issues.scala-lang.org/browse/SI-8217?orig=1
Reporter: @Blaisorblade
Affected Versions: 2.10.3

@retronym said:
This is basically a duplicate of #1753.

Previous discussion: https://groups.google.com/forum/#!topic/scala-user/MiKsvizQBd4

@Blaisorblade said:
#1753 is related and instructive, but incomplete. It only says that

class A { type T }

is intentionally allowed.

But what about objects? Why is the following forbidden?

object WTF_A0 {
  type T //Error: only classes can have declared but undefined members
}

I don't think that objects were indeed meant to be special.

Otherwise, the following should be also forbidden:

trait A {
  type T
}
 
object A extends A

If this inconsistency is by design, I'd demand more explanation than this:

I'm pretty sure it's been discussed before and it falls into the not-a-bug category.

Additionally, on the implementation level, the mere fact that the the check for undefined members is different from the check for undefined inherited members seem debatable — I guess the former can be done earlier, but it seems the two checks should still share logic.

@retronym said:
Related: scala/scala#3407

@Blaisorblade said (edited on Jan 31, 2014 7:06:26 PM UTC):
Adriaan seems to agree in this pull request: scala/scala-dist#127. I'm trying out the patch below, it does what I want, need to check for regressions. Before:

$ scala
Welcome to Scala version 2.10.3 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_51).
scala> object Foo {type A}
<console>:7: error: only classes can have declared but undefined members
       object Foo {type A}
                        ^

After:

$ ./qbin/scala
Welcome to Scala version 2.11.0-20140131-194308-ea897b018a (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_51).
scala> object Foo {type A}
defined object Foo

Fix:

--- a/src/compiler/scala/tools/nsc/typechecker/Namers.scala
+++ b/src/compiler/scala/tools/nsc/typechecker/Namers.scala
@@ -1617,6 +1617,7 @@ trait Namers extends MethodSynthesis {
         def symbolAllowsDeferred = (
              sym.isValueParameter
           || sym.isTypeParameterOrSkolem
+          || sym.isAbstractType
           || context.tree.isInstanceOf[ExistentialTypeTree]
         )
         // Does the symbol owner require no undefined members?

I'm also wondering about extending the check to concrete classes, while at it, since the reimplementation of these checks in refchecks is not run by the presentation compiler:

@@ -1623,7 +1624,8 @@ trait Namers extends MethodSynthesis {
         def ownerRequiresConcrete = (
              !sym.owner.isClass
           ||  sym.owner.isModuleClass
           ||  sym.owner.isAnonymousClass
+          ||  sym.owner.isConcreteClass
         )
         if (sym hasAnnotation NativeAttr)
           sym resetFlag DEFERRED

@Blaisorblade said:
I had forgot to link the pull request: scala/scala#3442.
(I let go of the second change I mentioned because things are not as easy, and I keep getting strange unexpected failures on it. Also, it's not related to this bug anyway).

@paulp said:

If this inconsistency is by design, I'd demand more explanation than this:

I'm pretty sure it's been discussed before and it falls into the not-a-bug category.

You and your wild ambitions. Once you're properly calibrated you will see that is an unusually clear and complete specification.

@Blaisorblade said:
I understand your point, but this is going to get fixed, and the clarification to the spec is already agreed on: scala/scala-dist#127

Now, it would be cool if somebody would explain the world the point of undefined type members more clearly (answer: they encode existentials), but I certainly can't explain that undefined type members are allowed as long as this bug is not fixed.

@adriaanm said:
Yes indeed! We fixed the spec before the compiler. I agree with the intent of the PR, but it needs some polish.
If we're going to allow abstract type members in classes, we should also allow them in objects, especially since they are already indirectly allowed by extending such a class.

@Blaisorblade said:
This was fixed in scala/scala#4024, time to close :)