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)

But we seem to have a lot of need for stuff in-between: emplace for classes, @disable this and move/moveEmplace for structs.

Just tossing this out there: What if there was a third version, an alternate to struct that:
- Prohibited implicit copying (perhaps unless the compiler knew the original was never used again?)
- Was always passed by moving (except where the compiler can determine it can safely and more efficiently pass by reference)?
- And, after passing it to a function, it would automatically be moved back to the caller (unless compiler can determine it doesn't have to bother).

Ie:
Move-Structs:
- Default Storage: Stack
- Indirection Overhead: No
- Semantics: Reference-like
- Passed By: Moving the Data (except where compiler...blah blah blah)

IIUC, this would give it the *effect* of reference semantics, but without the indirection (and vtable) overhead, and would allow it to perform RAII cleanup in its dtor when it goes out of scope without ever needing reference counting.

Is this nothing more than reinventing the future "struct with copy constructor and @disable-ed default constructor...and...maybe some other necessary part of the idiom I'm overlooking"?

Is it really just (badly) re-inventing some other XYZ except for differences UVW?

Or would this be a horrible thing to exist?

Any tweaks that would change it from a horrible idea to a fantastic one?

Or is it all just total nonsense?

On Tuesday, 4 September 2018 at 03:38:41 UTC, 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)
>
> But we seem to have a lot of need for stuff in-between: emplace for classes, @disable this and move/moveEmplace for structs.
>

Actually there's even more overlap.  `scope`-decorated classes are allocated on the stack.  `new`-allocated structs are allocated on the heap.  We have both `ref` and pointers for reference semantics on value types and structs.

There are also a few additional differences.  classes can inherit implementations, but using the technique illustrated in https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html, you can get something very much like classes.  With `alias this` and multiple-`alias this` (https://github.com/dlang/dmd/pull/8378) it gets even better.

> Just tossing this out there: What if there was a third version, an alternate to struct that:
> - Prohibited implicit copying (perhaps unless the compiler knew the original was never used again?)
> - Was always passed by moving (except where the compiler can determine it can safely and more efficiently pass by reference)?
> - And, after passing it to a function, it would automatically be moved back to the caller (unless compiler can determine it doesn't have to bother).

In my opinion, we shouldn't add a third option.  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.

My suggestion:  forget about ProtoObject and investing more into the resource pit that is classes.  Just make a better struct and supporting features so noone would even want to use classes anymore.

> Ie:
> Move-Structs:
> - Default Storage: Stack
> - Indirection Overhead: No
> - Semantics: Reference-like
> - Passed By: Moving the Data (except where compiler...blah blah blah)
>
> IIUC, this would give it the *effect* of reference semantics, but without the indirection (and vtable) overhead, and would allow it to perform RAII cleanup in its dtor when it goes out of scope without ever needing reference counting.
>
> Is this nothing more than reinventing the future "struct with copy constructor and @disable-ed default constructor...and...maybe some other necessary part of the idiom I'm overlooking"?
>
> Is it really just (badly) re-inventing some other XYZ except for differences UVW?
>
> Or would this be a horrible thing to exist?
>
> Any tweaks that would change it from a horrible idea to a fantastic one?
>
> Or is it all just total nonsense?

It's not nonsense, but unless you're willing to invest your time and effort into doing something about it, it's equivalent to nonsense.

Mike

On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote:
> There are also a few additional differences.  classes can inherit implementations, but using the technique illustrated in https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html, you can get something very much like classes.  With `alias this` and multiple-`alias this` (https://github.com/dlang/dmd/pull/8378) it gets even better.
>
> [...]
>
> In my opinion, we shouldn't add a third option.  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.

You can implement inheritance in C, if you really want to, but doing it by hand is far less productive and far more error prone than using a compiler that does it for you.

Now, with D's metaprogramming capabilities, it may well be possible to implement an object system as a library, using only structs. Without AST macros, though, a library solution is always going to have uglier syntax and worse error messages than a language feature with compiler support.

If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative.

On Tuesday, 4 September 2018 at 03:38:41 UTC, 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)
>
<snip>
> IIUC, this would give it the *effect* of reference semantics, but without the indirection (and vtable) overhead, and would allow it to perform RAII cleanup in its dtor when it goes out of scope without ever needing reference counting.

 I have been wanting a hybrid to a class/struct. Which is more the C++ struct of old. Namely stack based, and inheritance. Where it would differ is only having like 1-2 levels you could do inheritance, namely for building very similar structures while using the same base. Good for smaller building blocks (and variants of a struct/idea), not for making huge projects with.

On 04/09/2018 4:24 PM, Paul Backus wrote:
> On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote:
>> There are also a few additional differences.  classes can inherit implementations, but using the technique illustrated in https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html, you can get something very much like classes.  With `alias this` and multiple-`alias this` (https://github.com/dlang/dmd/pull/8378) it gets even better.
>>
>> [...]
>>
>> In my opinion, we shouldn't add a third option.  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.
> 
> You can implement inheritance in C, if you really want to, but doing it by hand is far less productive and far more error prone than using a compiler that does it for you.
> 
> Now, with D's metaprogramming capabilities, it may well be possible to implement an object system as a library, using only structs. Without AST macros, though, a library solution is always going to have uglier syntax and worse error messages than a language feature with compiler support.
> 
> If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative.

You also loose loads of stuff like extern(C++) classes interop and COM. Definitely a net negative. Even with a concept like signatures, you just can't replace the class/interface system.

On Tuesday, 4 September 2018 at 06:32:02 UTC, rikki cattermole wrote:
>> If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative.
>
> You also loose loads of stuff like extern(C++) classes interop and COM. Definitely a net negative. Even with a concept like signatures, you just can't replace the class/interface system.

Even in betterC? Last I checked classes pulled TypeInfos and all the stuff. What's the problem to use COM without classes? I do it.

On 04/09/2018 11:47 PM, Kagamin wrote:
> On Tuesday, 4 September 2018 at 06:32:02 UTC, rikki cattermole wrote:
>>> If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative.
>>
>> You also loose loads of stuff like extern(C++) classes interop and COM. Definitely a net negative. Even with a concept like signatures, you just can't replace the class/interface system.
> 
> Even in betterC? Last I checked classes pulled TypeInfos and all the stuff. What's the problem to use COM without classes? I do it.

Being able to define and use COM as it was intended (via classes) is a feature of D.

Looks like it could be pretty straight forward to get it working in -betterC, since what it isn't complaining about is TypeInfo. Keep in mind, IUnknown is its own root, just like Object and has a completely different ABI for vtable's and such.

test.obj(test)
 Error 42: Symbol Undefined __D6object6Object8opEqualsMFCQtZb
test.obj(test)
 Error 42: Symbol Undefined __D6object6Object5opCmpMFCQqZi
test.obj(test)
 Error 42: Symbol Undefined __D6object6Object6toHashMFNbNeZk
test.obj(test)
 Error 42: Symbol Undefined __D6object6Object8toStringMFZAya
test.obj(test)
 Error 42: Symbol Undefined __D4test3Foo7__ClassZ

On 2018-09-04 06:03, Mike Franklin wrote:

> My suggestion:  forget about ProtoObject and investing more into the resource pit that is classes.  Just make a better struct and supporting features so noone would even want to use classes anymore.

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

-- 
/Jacob Carlborg

On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote:
> In my opinion, we shouldn't add a third option.

Agreed.

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

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.


-Alex