Make 'abstract' mandatory if the class is intended to be abstract, absence of 'abstract' means "not abstract"

[Graham St Jack]

I agree

On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig wrote:

> A class can either be abstract or not abstract. Currently in D, if you
> don't mark a class as abstract, it can still be it if it contains an
> abstract method:
> 
> class Foo {
> 	
> 	abstract void someAbstract();
> 	
> 	void nonAbstract() {
> 	}
> 	
> }
> 
> When designing a class, you have in mind whether the class is going to
> be abstract or not. If it's not going to be abstract, you want the
> compiler to help you by telling you "You made a mistake. This class is
> still abstract because you didn't implement method foo".
> 
> So I want to extend Foo with a class Bar, but I want Bar to be not
> abstract.
> 
> class Bar : Foo {
> }
> 
> I compile, and it gives no error, of course. But I want there to be an
> error there. The only way I can get an error is by making a dummy
> function that instantiates Bar:
> 
> void blah() {
> 	Bar bar = new Bar();
> }
> 
> main.d(14): Error: cannot create instance of abstract class Bar
> main.d(14): Error: function someAbstract is abstract
> 
> The problems with this appraoch are two:
>   - You have to make a dummy function to check whether you implemented
> Bar correctly.
>   - You get two errors for each instantiation of Bar, if it's abstract
> (ugly).
> 
> Why not make "abstract" mandatory for a class if it's intended to be
> abstract, and the absence of "abstract" to mean "not abstract"? Java
> works this way, and I think it is for the reasons I mentioned.
> 
> Another advantage is that just by seeing the start of class definition
> you can tell whether a class is abstract or not. You don't have to see
> if any method is marked as abstract, or go to the superclasses to see if
> there is a method that is still not implemented.
> 
> (also, it would be nice if the compiler could tell you all the methods
> that still need an implementation, rather than just one)