[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2946

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P3  |P4

--

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2946

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||dmitry.o...@gmail.com

--

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2946

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2946

Denis Shelomovskij verylonglogin@gmail.com changed:

   What|Removed |Added

 CC||verylonglogin@gmail.com

--- Comment #13 from Denis Shelomovskij verylonglogin@gmail.com ---
1. Currently `abstract` in required if not all `interface` methods are
implemented or overridden with an `abstract` method:
---
interface I { void f(); }

abstract class CI1: I { } // `abstract` required
abstract class CI2: CI1 {  } // `abstract` required too

class B { abstract void f(); }
class CB: B {  } // derived as `abstract`

class CI3: I { abstract void f(); }
class CI4: CI3 {  } // derived as `abstract` too
---
This difference looks inconsistent.

2. When one sees a class `C` and want to understand whether or not it is
abstract he has to look through every ancestor of `C` to determine whether it
contains an `abstract` method unimplemented further. And it's really hard. IMO
it would be much better if class declaration clearly shows whether it's
abstract or not.

3. Currently a compiler prints what methods are unimplemented if one tries to
create an abstract class instance so this isn't a critical issue, just a bad
looking thing in a language (IMHO).

--

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946


Stewart Gordon s...@iname.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |


--- Comment #9 from Stewart Gordon s...@iname.com 2013-01-21 05:27:53 PST ---
(In reply to comment #8)
 I don't think this will fly.

It's up to Walter whether this will be implemented.

 Abstract on the class name itself makes it non-instantiable, 
 however subclasses are not abstract and can be instantiated:

It isn't clear to me what relevance this has.  The point of this request is to
require abstract classes to be declared as abstract.  You're talking about
classes that already are declared as abstract.

 Whether or not there's an abstract keyword next to the class name 
 doesn't tell you whether the class actually has abstract methods, 
 so there's no benefit forcing you to add 'abstract' to the name.

It isn't supposed to tell you whether it has abstract methods.  It's supposed
to tell you whether the class is abstract, i.e. barred from direct
instantiation.

With the abstract attribute being optional on the class declaration itself, one
has to look through all the methods to determine whether the class is abstract
or not.  With it being mandatory, the information is right in front of you when
you look at the class.

It would also be useful for documentation generators.  Whether a class has any
abstract methods depends not only on methods declared directly within the body
of the class, but also on those in superclasses of the class, interfaces the
class implements, and method declarations generated by mixins.  The last of
these effectively means that no standalone documentation generator (unless it
contains a full D conditional compilation and CTFE engine) can correctly
indicate which classes are abstract and which aren't.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946


Jacob Carlborg d...@me.com changed:

   What|Removed |Added

 CC||d...@me.com


--- Comment #10 from Jacob Carlborg d...@me.com 2013-01-21 11:12:53 PST ---
(In reply to comment #0)
  On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig
 A class can either be abstract or not abstract. Currently in D, if you 
 don't mark a class as abstract, it can still be it if it contains an 
 abstract method:
 
 class Foo {
 
 abstract void someAbstract();
 
 void nonAbstract() {
 }
 
 }
 
 When designing a class, you have in mind whether the class is going to 
 be abstract or not. If it's not going to be abstract, you want the 
 compiler to help you by telling you You made a mistake. This class is 
 still abstract because you didn't implement method foo.
 
 So I want to extend Foo with a class Bar, but I want Bar to be not abstract.
 
 class Bar : Foo {
 }
 
 I compile, and it gives no error, of course. But I want there to be an 
 error there.

There might be a problem with this since D supports separate compilation. There
can be another object file that contains the implementation of
Bar.someAbstract. I'm not sure if this applies here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #11 from Stewart Gordon s...@iname.com 2013-01-21 12:40:39 PST ---
(In reply to comment #10)
 There might be a problem with this since D supports separate 
 compilation. There can be another object file that contains the 
 implementation of Bar.someAbstract. I'm not sure if this applies 
 here.

No, for this to apply, Bar would need to contain its own declaration of
someAbstract.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
   Platform|x86 |All
 Resolution||WONTFIX


--- Comment #8 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-20 
12:26:13 PST ---
I don't think this will fly. Abstract on the class name itself makes it
non-instantiable, however subclasses are not abstract and can be instantiated:

// can't be instantiated
abstract class Foo { void foo() { } }  

// is not abstract and can be instantiated
class Bar : Foo { }

Whether or not there's an abstract keyword next to the class name doesn't tell
you whether the class actually has abstract methods, so there's no benefit
forcing you to add 'abstract' to the name.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #5 from Stewart Gordon s...@iname.com 2010-10-30 05:57:20 PDT ---
(In reply to comment #4)
 This is a case where the specs are suboptimal, so this is not a true
 enhancement request, it's a way to fix a little mistake in the D specs.

Have you evidence that this is a mistake, i.e. not what Walter intended to
write?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #6 from bearophile_h...@eml.cc 2010-10-30 14:56:35 PDT ---
(In reply to comment #5)
 Have you evidence that this is a mistake, i.e. not what Walter intended to
 write?

I have no evidence, but regardless the origin of this current situation, the
Java design is the correct one (unless someone shows me otherwise) and I think
here it's better to modify D specs  implementation. And I think it's better to
do this change as soon as possible, before lot of D2 code is written, to reduce
troubles of fixing code later.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #7 from Stewart Gordon s...@iname.com 2010-10-30 17:22:30 PDT ---
Certainly the Java design is more sensible on this.  But correct in terms of
design is to some degree a matter of opinion.  There are a number of aspects of
D's design that I would consider mistakes - inheritance protection, archaic
switch syntax, implicit narrowing conversions just to name a few.  There are
probably lots filed here.  How would we label such issues on this basis,
anyway?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #4 from bearophile_h...@eml.cc 2010-10-29 05:01:02 PDT ---
(In reply to comment #2)
 The compiler is behaving correctly, therefore this is an enhancement request.

We need a different term to tell apart true enhancement requests (where someone
asks for a new feature or new subfeature) from bugs in the specs.

This is a case where the specs are suboptimal, so this is not a true
enhancement request, it's a way to fix a little mistake in the D specs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2946





--- Comment #1 from g...@nwawudu.com  2009-05-06 10:17 ---
Another example.

main.d
--
class Foo1 {
abstract void foo();
}

class Bar1 : Foo1 {
}

abstract class Foo2 {
abstract void foo();
}

class Bar2 : Foo2 {
}

void main () { 
debug {
auto f1 = new Bar1;
auto f2 = new Bar2;
}
}

C: dmd -w -debug main.d
main.d(17): Error: cannot create instance of abstract class Bar1
main.d(17): Error: function foo is abstract
main.d(18): Error: cannot create instance of abstract class Bar2
main.d(18): Error: function foo is abstract

Should not compile or at least give a warning, but does neither.
C: dmd -w main.d


--