Variables of struct and class types are called objects - discuss

[Jonathan M Davis]

On Sunday, August 3, 2025 9:31:34 AM Mountain Daylight Time Paul Backus via Digitalmars-d-learn wrote:
> I have never seen any D programmer use "object" to mean "struct
> or class instance."

That is always how I use the term. I see no reason to differentiate between
what an instance of a struct is called and what the instance of class is
called any more than they do in C++, where (as I'm sure you're well aware)
struct and classes are basically the same thing, and there are plenty of
classes which don't use inheritance at all, making them pretty much just
like D structs.

And from what I've seen, folks routinely use the term object for instances
of structs in D, and since D code typically uses structs more than classes,
I expect that the term object is actually used to refer to structs in D far
more than classes. I don't recall previously ever having seen anyone try to
argue that instances of structs aren't objects, and the term object comes up
enough in D discussions that I have a hard time believing that it's
typically been intended to only mean instances of classes. But It's
certainly possible that my preconceptions on the matter have colored my
understanding of what people have said.

Honestly, I suspect that there are times where even instances of built-in
types such as int or int[] get referred to as objects, since it's a
convenient way to refer to an instance of a type (and it's not like everyone
is always precise with their language). Personally, I wouldn't normally use
the term object in such a fashion, but I wouldn't be surprised if I have
some of the time simply because when talking about generic code, and you
want to talk about the instance of the type being used, it's quite easy to
just end up using the term object instead of talking about the instance of
the type, particularly when it's frequently going to be a struct or class
anyway.

> The standard term for grouping together
> structs and classes is ["aggregate,"][4] as in "aggregate type"
> or "aggregate instance."

The spec does use the term "aggregate type" to refer to classes, structs,
interfaces, and unions, since they're all aggregates of values. However,
from what I've seen, the term isn't used very often outside of the spec, and
I don't think that I've ever seen the term "aggregate instance" before. From
what I've seen, instances of both structs and classes are routinely referred
to as objects.

Though thinking on it now, the situation is a bit weird with unions. The
spec does say that user-defined types are aggregate types, and
isAggregateType in std.traits is true for unions, but it can only have a
single value at a time, meaning that it isn't an aggregate in the sense that
it has multiple values. But it _is_ an aggregate in the sense that it can
hold different types of values. Either way, it's a bit weird (though
arguably, unions are just weird in general). However, as far as the
isAggregateType trait goes, it probably does fit in with why you'd be using
the trait, because you need to know whether it has members that you have to
deal with, and unions do fall into that camp.

And thinking on it, I wouldn't really want to call unions objects, either
because they can't have member variables or because I wouldn't ever consider
passing an instance of a union around. I'd normally ever use a union for a
member variable where it was encapsulated carefully, so I wouldn't be
passing it around, and it wouldn't be part the API, so I wouldn't normally
have any instances of it floating around to even be referred to as objects.

Regardless, it's not like we have a precise definition of what "object"
means in D in the spec anywhere AFAIK. And the way that folks use it is
probably strongly colored by their experience with other languages.

- Jonathan M Davis