Abstract functions in child classes

[Christophe]

FWIW, I agree with Addam. One of the things I like in D is that the 
langage is designed so that interpretations are made based on what you 
intend, and what you intend to do is checked. That is exactly what is 
done by using overwrite keyword. If you intend to make a non-abstract 
class, the compiler should check it is non-abstract and complain if it 
is not. This way, the error message pops where it belongs, i.e. at the 
class definition, not somewhere in another file where it is 
instanciated. It is not hard to add a specific unittest close to the 
class definition to test instanciation, but this is still much harder 
than writing 'abstract' at the beginning of the class definition when 
you intend to make it abstract (which is also much shorter than writing 
a sentence to indicate that the class is abstract in the documentation).

For special use-cases, when you don't know if the class is abstract or 
not because it is a template, you should just be allowed to write 
something like 'auto abstract' and the problem is solved.

Is is a really a larger pain to make this correction early to the 
langage, than to keep this little misfeature for years ? With an 
appropriate (and optional) warning to tell abstract class will soon have 
to be declared such for several years before there is an (optional) 
error, and maybe even a patch to make the correction automatically, that 
should not be such a pain.

-- 
Christophe