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