Abstract functions in child classes

[Steven Schveighoffer]

On Fri, 02 Dec 2011 17:28:33 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Friday, December 02, 2011 21:13:45 Adam wrote:
>> Anyway, I have my answer, and I know that D *does* have a reason for
>> this implicitism.
>
> Okay. Maybe I've been skimming over this thread too much, but I don't
> understand what forcing the programmer to mark an abstract class as  
> abstract
> would do. The compiler knows that the class is abstract regardless. It's  
> going
> to generate an error when you try and instantiate that class - whether  
> or not
> you mark the class as abstract or not has no impact on that as long as  
> there
> are abstract functions (the sole bizareness being able to mark a class as
> abstract when none of its functions are abstract).

If I may describe what I see as the argument for (while trying to avoid a  
strawman), the benefit of requiring abstract is so the compilation of the  
class fails, not the isntantiation of the class.

It's feasible that someone could run tests that don't ever instantiate  
that exact class type, and then they wouldn't know it wasn't  
instantiable.  This is similar to someone who writes a library of  
templated objects, but doesn't test certain instantiations of them,  
finding out only later that it doesn't work.  I actually have been  
affected by this, since dcollections is all templates.  For example,  
containers of interfaces didn't work, but I didn't know until one of  
dcollections' users tried to do it.  Then I installed a workaround.

So to summarize, it's compiler error on declaration vs. compiler error on  
instantiation.  The question then becomes, given an expected concrete  
class, what is the probability that nobody tries to instantiate it during  
testing?  The worst case scenario is that the end-user's code doesn't  
compile.

> The only thing that I see that marking the class abstract does is give  
> the
> programmer a visual indicator that the class is abstract. I do think that
> that's valuable, and I'd love it if it were required when any functions  
> in the
> class are abstract and disallowed when none are, but I don't see how it  
> can
> have any effect on what errors you're getting. It's instatiating an  
> abstract
> class which as error, not declaring one, and unless you actually  
> instantiate
> it, there's no way for the compiler to catch it, because there's nothing  
> to
> catch.

This can be fixed via ddoc (which should know the class is abstract).

In fact, I think it does mark it as abstract in documentation (I know it  
marks interfaces as abstract unnecessarily).

-Steve