View mode: basic / threaded / horizontal-split · Log in · Help
December 05, 2011
Re: Abstract functions in child classes
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.

December 05, 2011
Re: Abstract functions in child classes
On Fri, 02 Dec 2011 17:28:33 -0500, Jonathan M Davis <>  

> 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  

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

Next ›   Last »
1 2 3 4 5
Top | Discussion index | About this forum | D home