Why there are no 'physical' object variables (only references)?

[Lutger]

Steve Horne wrote:
  > But pragmatism beats ideology every time. In C# and D the implicit
> references work well, for me. There seems to be an intuitive divide
> between 'object' and 'value'. For a 'value', I expect parameter
> passing to have copy semantics. For an 'object' I expect sharing
> (reference) semantics.
> 
> Maybe it's something to do with the real world. It's just natural to
> work with existing objects - not duplicates of those objects. When I
> was told to clean my room as a child, I don't think stories about
> duplicating the room, cleaning the duplicate and discarding it would
> have worked ;-)
> 
> With 'values' - numbers etc - copy semantics seem more sane. In
> algebra, calculating the unknowns does not alter the known values.
> Outputs are based on inputs, not the other way around. Even feedback
> has a time delay - the calculation of the output doesn't change its
> input, it just provides a new input for the next millisecond or
> whatever.

Well said. I needed some time to adjust to the reference semantics of 
classes in D and it's less (than C++) capable struct type. But now I'm 
used to it, it really makes sense.

Besides some minor details, in C++ a struct is the same as a class. But 
in D they really are different beasts, making the distinction and when 
to use which one easier. In C++ you have to think all the time about 
reference vs value semantics and take care of what happens in the 
assignment operator and copy constructor, and not only wrt memory 
allocation.

Even though you don't have the standard syntactic sugar of struct 
construction and copying in D, the way it works now is intuitive enough 
  and - imho - makes for a more productive and safe way of doing things. 
Assignment can be a dangerous operation and in D you can be sure of what 
happens at least.