Random thought: Alternative stuct

[Jonathan M Davis]

On Wednesday, September 5, 2018 1:49:31 PM MDT H. S. Teoh via Digitalmars-d 
wrote:
> 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.

And as Andrei talked about in his dconf talk, that's being fixed by adding
ProtoObject as the new root class type. Some of the details may still need
to be sorted out, and it needs to be implemented, but we have a fairly clear
path forward on that. The major downside to it is that there are no plans to
deprecate Object as part of it, but that could change later, and even if it
doesn't, new code will generally be able to avoid Object and the problems
that come with it.

- Jonathan M Davis