December 05, 2011
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
On Fri, 02 Dec 2011 17:28:33 -0500, Jonathan M Davis <> 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).

Next ›   Last »
1 2 3 4 5