Most of this has been mentioned before, I'm kind of putting it all in one place.

This program compiles and runs without error:

----------
import std.stdio;

abstract class Qwert {}

class Yuiop {
abstract int asdfg(int hjkl) {
return hjkl * 2;
}
}

void main() {
Qwert zxcvb = new Qwert;
Yuiop nm = new Yuiop;

writefln(nm.asdfg(42));
}
----------

I have identified four things wrong:

1.  Abstract isn't documented at all.

2.  It allows me to instantiate Qwert, even though I have explicitly declared it as abstract.

3.  Yuiop.asdfg is declared as abstract and has a body.  What a contradiction!

4.  Going away from this testcase, the error message on trying to instantiate an abstract class is far from adequate.  Consider this:

----------
class Qaz {
abstract int wsx(int edc);
}

class Rfv : Qaz {}

void main() {
Rfv tgb = new Rfv;
}
----------
D:\My Documents\Programming\D\Tests\bugs\abstract2.d(8): cannot create instance of abstract class Rfv
----------

If the base class has lots of abstract methods, trying to pinpoint which one hasn't been implemented can be a nightmare.  Even more so if you have a deep hierarchy of abstract classes, each of which implements some of the abstract methods of its base and possibly adds more abstract methods of its own.

As I think I said before, I would've gone for requiring abstract to be explicitly declared.  Was this decided against or just overlooked? Meanwhile, we'd better make the compiler error more helpful.

We ought to have a two-line error like in Borland C++:

D:\My Documents\Programming\D\Tests\bugs\abstract2.d(8): cannot
create instance of abstract class Rfv
D:\My Documents\Programming\D\Tests\bugs\abstract2.d(2): class Rfv is
abstract because of abstract member function wsx

Having two lines would enable editors such as TextPad to locate both lines of interest: the line that triggered the error, and the line where the abstract member was declared.  The latter is handy for seeing the function signature and in which class it is actually specified, though some of this info could be incorporated into the error message.

Stewart.

In article <cj0qf6$2u2v$1@digitaldaemon.com>, Stewart Gordon says...
>
>3.  Yuiop.asdfg is declared as abstract and has a body.  What a contradiction!

This should be legal.  I consider it equivalent to the following C++ syntax:

# class C {
# public:
#     virtual void func() = 0 { ... }
#};

This requires that the function be implemented in subclasses but offers a default implementation.  ie.

# class B : C {
# public:
#     void func() { C::func(); }
# };


Sean

In article <cj1cjs$67c$1@digitaldaemon.com>, Sean Kelly says...

> In article <cj0qf6$2u2v$1@digitaldaemon.com>, Stewart Gordon says...
> 
>> 3.  Yuiop.asdfg is declared as abstract and has a body.  What a contradiction!
> 
> This should be legal.  I consider it equivalent to the following C++ syntax:
<snip>
> This requires that the function be implemented in subclasses but offers a default implementation.  ie.
<snip>

I hadn't heard of that C++ feature - it seems C++ has more uncharted (by me, anyway) territory than I had imagined.  And I'm not sure how much practical use it would have.  But that clearly isn't what's happening.  Maybe we could vote on whether such a feature's worth it, or see what Walter says....

Stewart.

Just been looking through and been reminded of another of these bugs.

5. Member variables can be declared as abstract, although by nature they don't override.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/599

Stewart.