final abstract class should not be permitted by compiler

[scabug]

classes which are final and abstract should not be allowed by the compiler because they are ludicrous

final abstract class Base {

}

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9464?orig=1
Reporter: Stefan Baritchii (bstefan2)
Affected Versions: 2.11.5

[scabug]

@retronym said:
We actually use this combination of modifers in the standard library for classes that should never be instantiated, such scala.Boolean which stands for the primitive JVM boolean.

I'm going to close this as out-of-scope, as it would still be a useful warning for most people. Our policy for this sort of thing is to encourage logging an issue (or contributing a patch) contribution to scala-abide, our nascent linting tool: https://github.com/scala/scala-abide/issues

[scabug]

Jasper-M said:
It's a bit strange that at the same time:

scala> final trait Foo
<console>:11: error: illegal combination of modifiers: abstract and final for: trait Foo
       final trait Foo
                   ^

[scabug]

@som-snytt said (edited on Jan 24, 2017 6:52:04 PM UTC):
The mysterious incantation in the standard library doesn't actually compile without magic. It seems to me that the private constructor suffices to signal non-instantiation. In fact a constructor can be private[this]. Unfortunately, secondary constructors can still invoke it.

Otherwise, words here: scala/scala#5660

[scabug]

@adriaanm said:
Types that cannot be instantiated can still be useful in certain situations, so I don't think we should rule this out. I'm wondering why classes and traits should be specified to behave differently with respect to how they interact with the final modifier.

[scabug]

@som-snytt said:
By extension, is this a useful way to say T has no instances?

trait T { final def f: Unit }

There is a balance to be struck between "that's stupid, you're not expressing something useful" and "OK, maybe there's a use case for that."

Also, should the compiler say "that's stupid", or is that the job of the REPL or Abide?

What about

trait F { def f: Unit }
package impl { trait T extends F { override final def f: Unit } }

where the API requires T but which will never be supplied in fact? I guess that's a badly designed API.

[scabug]

@adriaanm said:
There are so many examples of classes/traits that cannot be instantiated:

trait X { nope: Nothing => } // good luck

We could warn under one of the nonsense-fighting flags, but not by default.