Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

final abstract class should not be permitted by compiler #9464

Closed
scabug opened this issue Sep 8, 2015 · 7 comments
Closed

final abstract class should not be permitted by compiler #9464

scabug opened this issue Sep 8, 2015 · 7 comments

Comments

@scabug
Copy link

scabug commented Sep 8, 2015

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

final abstract class Base {

}

@scabug
Copy link
Author

scabug commented Sep 8, 2015

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

@scabug
Copy link
Author

scabug commented Sep 8, 2015

@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 scabug closed this as completed Sep 8, 2015
@scabug
Copy link
Author

scabug commented Jan 24, 2017

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
Copy link
Author

scabug commented Jan 24, 2017

@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
Copy link
Author

scabug commented Feb 7, 2017

@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
Copy link
Author

scabug commented Feb 7, 2017

@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
Copy link
Author

scabug commented Feb 8, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants