new principle of division between structures and classes

[Weed]

Denis Koroskin пишет:

> Back to topic, C++ doesn't have any meaningful separation between
> classes and structs. D does - (one of it is that) classes are heap
> allocated by default whereas structs are stack allocated by default. You
> can override either behavior:
> 
> class C {}
> struct S {}
> 
> C c = new C(); // heap-allocated (default)
> S s = S(); // stack-allocated (default)
> 
> scope C c = new C(); // stack-allocated

This way does not approach because scope value is impossible to return
from function.

> S* s = new S(); // heap allocated
> 
> One problem I see with it is that the syntax is so much different, but
> that's another topic.
> Other one is that the following works for local variables exclusively,
> i.e. you can't have class instance aggregated inside another class by
> value.

I am not understand what here a problem with class inside other class.

> Yes, I think there is a room for improvement but it is of little
> priority for me.
> 
> You don't provide use cases nor examples of possible syntax, but they
> are crucial for understanding.

I still was not sure what syntax could. While I operate with the such -
probably, it don't break an existing code:

class C {}
struct S {}

C c = new C(); // heap-allocated
S s; // stack-allocated
S s = S(); // stack-allocated
S* s = new S(); // heap allocated

C c(); // stack-allocated (added by me)

Brackets () do not allow to mix object with the reference. Also, they
may contain constructor parameters.

Further objects are used as usually.

> What else?
> 
> Struct inheritance - yes it is nice to have, even without polymorphism.
> It was proposed many times but with no success. Someone suggested to use
> aggregation and opDot instead and allow implicit cast of pointer to
> struct to pointer to struct's first element to emulate inheritance:

Inheriting of structures is necessary for convenience of replacement
"struct" to "class" and vice versa. Therefore possibility of replacement
of struct inheritance on other constructions it is not essential.


> I'd suggest you to state you ideas as simple and keep your posts as
> small as possible (trust me, few people like reading long posts). You
> could also ask someone to check your post before submitting - this will
> increase the probability of your message to be read and understood.

I agree, but the changes offered by me separately look as unreasonably,
and only in the sum they yield good result.

Thanks for kind words :)