On Wed, Sep 05, 2018 at 07:21:51PM +0000, kinke via Digitalmars-d wrote: > On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote: [...] > > Rather, we should deprecate classes, and make and expand the > > capabilities of structs. Languages like Zig and Rust have done away > > with classes and all runtime overhead that accompanies them, and are > > showing great promise by expanding on structs with much more > > composable features. > > I'm not familiar with the mentioned languages, but I definitely > wouldn't want to miss classes for good old polymorphism. I'm not too > fond of the implicit monitor field, but otherwise I find the > struct/class distinction in D more or less perfect.
+1. I think the current class/struct divide is perfect. Classes being intended for runtime polymorphism (which *does* have its uses, in spite of OO fanatics attempting to shoehorn every problem into it, which is the reason for the resentment against it) obviously makes sense to be allocated on the heap by default and passed around by reference. Structs being glorified ints obviously should be fixed size and passed by value. The current issues with classes stems really from poor quality of implementation rather than an actual, fundamental problem with the design. The monitor field is an unnecessary, cumbersome overhead that we could do without, as are opEquals, toString, and their ilk (esp. given the problem of attribute incompatibilities). So what we should fixing is the implementation of classes, not throwing out classes with the polymorphic water completely. T -- INTEL = Only half of "intelligence".