Structs as reference types?

[Alexandru Ermicioi]

On Sunday, 30 May 2021 at 11:17:03 UTC, sighoya wrote:
> On Sunday, 30 May 2021 at 07:04:29 UTC, Alexandru Ermicioi 
> wrote:
>> From the looks of the request, what he wanted is to have 
>> mainly reference semantics, which classes already have.
>
> My gut feeling is that structs are in favor toward classes. 
> Both aren't really interconvertible and if you don't use 
> templated code you have to decide between structs, classes and 
> interfaces.
That's the point, each of them has their own use. What use cases 
are trying to cover by having ptr struct type?
> Examples are the container structures in D which seem to be 
> stucts. We may say that passing them by value is optimized out, 
> however value fields have still to be copied in certain cases 
> which is unnecessary.
They are usually structs because, most of containers will also 
want to inherit atributes of the struct methods (it's operator 
overloads) such as @safe, pure, @nogc and etc. if, you're 
referring to custom containers. It is literally impossible to 
design a collection interface that will inherit attributes from 
the structure it will hold.

> Passing them by ref is fine but that holds only for stack 
> allocated structs?
Ref should work for heap allocated ones too, you just need to 
dereference them.
> Moreover, there are no `ref T` types making it hard to 
> instantiate type parameters with ref structures.
There is 'auto ref' for templated functions.
>
> For heap structs, we have pointers, but it sucks to create 
> aliases all the time to hide the pointer in the name of the 
> pointer struct.
>
>> It would be nice if the proto object proposal would get 
>> implemented. It would cleanse a bit the Object hierarchy and 
>> would allow use classes as structs (well still a bit fatter) 
>> without extern (c++).
>
> Interesting, did you have a link.
>
> Further, I'm also in favor of adding:
>
> ```D
> ref struct S
> {
>    int i;
> }
> ```
>
> which wouldn't be covered by the proposal?
Https://forum.dlang.org/post/pa1lg6$1lud$1@digitalmars.com -> 
note this will not make classes equal to structs with reference 
semantics, it just reorganizes what already exists in Object 
class giving you more options of what features to use. It won't 
cover your case probably, that's why I said it still would be a 
bit fatter in memory footprint.
> Really, I would like to make structs and classes more equatable 
> to each other, switching between them sucks.
Well, this will be hard to do probably, because classes have one 
more feature they implement which is polymorphism, while structs 
are designed to be plain structures with some behavior.

Anyway, it would be nice to know clearly, what usecases you want 
to cover by that proposal. The only one I've noticed, is 
reference semantics, which can be covered by extern c++ final 
class (not as short as your example, but it works).