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".

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

On Wednesday, September 5, 2018 1:34:40 PM MDT 12345swordy via Digitalmars-d wrote:
> On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote:
> > In my opinion, we shouldn't add a third option.  Rather, we should deprecate classes, and make and expand the capabilities of structs.
>
> If D deprecate classes, then I will stop using D entirely. I was initially drawn by D for a "better-C++" and that includes classes.

I don't think that you have anything to worry about on that count. That would be far too large a breaking change to be acceptable, and while most of us don't bother with classes much (since we usually only use them if we need runtime polymorphism), you're not going to find many of us agreeing that classes should be gotten rid of. And selling Walter and Andrei on such an idea would be a really hard sell - even more so when you consider stuff like C++ integration, which they consider to be very important.

- Jonathan M Davis

On Wednesday, 5 September 2018 at 18:41:15 UTC, Jacob Carlborg wrote:
> On 2018-09-04 06:03, Mike Franklin wrote:

> For that it needs to support all the features as classes do today. In that case, what would be the difference compared to classes?

Indeed, the idea is that structs, with a few additional features added to the language, should be able to fill the role classes fill today.

Polymorphism can be achieved in the library using methods similar to what Sarn demonstrated in the article I linked previously.  Features like mixins can cut down on the boilerplate; other boilerplate-removing features would likely be needed.  Multiple-alias-this and some form of `protected` for structs would be examples of additional features that would help to implement class-like behavior; again, others would also likely be needed.

Reference semantics can be achieved much like C++ does today with it's smart pointers and things like `T&`.  For example, D might have `GC<T>` for garbage-collected types, `RC<T>` for reference counted types, etc, so the ownership and reference semantics are delegated to a container type in concert with DIP1000-like features of some kind.

In general, classes, to me, are looking more and more like syntax sugar over existing fundamental language features, and I think with the right supplemental language features for reducing boilerplate and encapsulate details, something very much like classes can be implemented in the library.  I'm just thinking out-loud though.  I doubt something like this will happen, especially without me or someone else demonstrating such a thing with a thorough proof-of-concept implementation.

Mike

On 04/09/2018 3:38 PM, Nick Sabalausky (Abscissa) wrote:
> We have classes and structs:
> 
> Classes:
> - Default Storage: GC Heap
> - Indirection Overhead: Yes
> - Semantics: Reference
> - Passed By: Copying the Data's Address
> 
> Structs:
> - Default Storage: Stack
> - Indirection Overhead: No
> - Semantics: Value
> - Passed By: Copying the Data (except where the compiler can determine it can safely and more efficiently pass by reference...at least, IIUC)

Signatures:
- Default Storage: Heap (with help of scope so won't be GC'd)
- Indirection Overhead: Yes, one layer, no other way to do it if the backend can't optimize it out
- Semantics: Reference
- Passed By: Copying a pointer static array around (ref+scope can make this near free)
- Implementation support: Classes and structs

On 2018-09-06 07:17, Mike Franklin wrote:

> In general, classes, to me, are looking more and more like syntax sugar over existing fundamental language features

Technically a programming language _is_ syntax sugar.

-- 
/Jacob Carlborg