Why are structs and classes so different?

Kevin Bailey keraba at yahoo.com
Tue May 17 14:40:48 UTC 2022


Hi again Ali!

On Monday, 16 May 2022 at 21:58:09 UTC, Ali Çehreli wrote:
>
> I for one misunderstood you. I really thought you were arguing 
> that struct and class should be the same.

To be specific:
- My *primary* concern is that:

Foo foo;

is undefined behavior waiting to happen, that I can't detect at a 
glance.

- A *secondary* goal would be for class objects to be able to 
have deterministic destructors like structs.

The first looks trivial: Just have it allocate a Foo by default.

The second looks like it could have been designed that way, 
albeit with other minor changes to the language, and, I was 
curious why it wasn't.

> C++ is proof that it can indeed work the other way. However, 
> for it to work correctly, programmers must follow guidelines. 
> Here are four:

But again, from this discussion, it seems D could have simply had 
pass-by-reference for class objects, preserving everything D 
strives for, but by-value stack initialization, providing what 
people expect from stack objects. There's no need to drag C++ 
design into it.

> C++ does not use terms "value type" and "reference type" to 
> make any distinction but the rules above are proof enough for 
> me that C++ implicitly divides user-defined types into such 
> categories.

I would beg to differ here. In C++, all types are value types, 
until you add punctuation. This is one of the things that I like 
about C++, that I trip over in other languages. e.g. In Rust, 
there are 2 similar types, is it int and float, where one is 
copyable and the other move-only? How can you write generic code 
in that environment?

Yes, in C++, you have to worry about slicing and copying 
singletons, but these are problems in front of you. It's the 
problems that sneak up behind you that I worry about.

> Ok, I think I see better now. You would like members of a class 
> recursively placed next to each other in memory. What if a 
> polymorphic type had a polymorphic member?

You mean like a string? I don't have a problem with this:

class MyString {
    uint length;
    ...pointer to data...
}

void func() {
    MyString s;
    if (s.length == 0)  // I want this to be perfectly safe.
       writeln("empty");
    // 's' destroyed here, could do something useful
}

In D, some objects can do this; some can't!

> I don't understand that example. I see a programmer error of 
> casting a Foo to a Bar.

Correct, I was responding to a comment. I was pointing out that 
the only "slicing" that we need to worry about with by-reference 
is if we are already doing something wrong, and that D won't help 
you there.

> Did you mean C#? C# is like D: structs are value types and 
> classes are reference types.

You missed the part where I said, "ignoring structs". :-)

> With all due respect, based on other conversation here, may I 
> assume you those projects were based on C++? If you also had 
> any language with reference types like Python, did you have the 
> similar issues with those languages?

Python is a toy language, right? I'm not aware of any large 
projects in it. (The largest I worked with was 138 files, 31k 
lines - tiny.)

Java would be a better comparison, but it has auto-closable 
objects, unlike D and Python. Perhaps it has succeeded because 
there are so few types that *aren't* by reference. Perhaps one 
just gets used to it. (I've written Android apps, but I would 
never write a long-running service in it.)

This is unfortunate for D where you have to keep track.

> I accepted D's struct/class separation since the beginning and 
> never had any issue with it. It just worked for me.

Perhaps you are familiar with the types that you work with on a 
daily basis. Perhaps the project is small. Perhaps your IDE 
colors classes brightly. I don't know, but an anecdote doesn't 
mean much compared to the fact that nearly all large projects are 
in C++, and I don't mean "due to inertia." I mean, "and they're 
successful."



More information about the Digitalmars-d-learn mailing list