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

[Frits van Bommel]

Kristian wrote:
> I'm used for having both the variable types, 'physical' and 
> reference(/pointer) ones, so it feels strange to work with D (or Java, 
> etc) that have reference types only.
> 
> First, there is no way to copy/clone an object (in general). That is, 
> unless you provide a copy/clone function (for all the classes you're 
> using). Second, you cannot create classes that behave like basic types, 
> e.g. like integers.
> 
> For example, in C++ you could have:
> 
> void func() {
>     Coord a, b, c;
> 
>     a.set(1, 2);
>     b.set(5, 10);
>     c = a + b;  //'c' is (6, 12)
>     b = c;
>     b.setX(2);  //'c' is unchanged, 'b' is (2, 12)
> }
> 
> The 'Coord' objects have no 'global meaning' here, they are just simple 
> values used in calculations. (So there is no need to reference them from 
> other parts of the code.)
> 
> I think it's a big restriction if a language does not have both the 
> variable types (physical + references).
> Why D and other similar languages have no physical types?

I think D structs are the "physical" variable type you're looking for.
They allow everything above. The Coord type + minor modifications to 
your code for testing:

     struct Coord
     {
         int x,y;

         void set(int x_, int y_) { x = x_; y = y_; }

         void setX(int x_) { x = x_; }

         Coord opAdd(Coord c)
         {
             Coord ret;
             ret.x = x + c.x;
             ret.y = y + c.y;
             return ret;
         }
     }

     void main() {
         Coord a, b, c;

         a.set(1, 2);
         b.set(5, 10);
         c = a + b;  //'c' is (6, 12)
         b = c;
         b.setX(2);  //'c' is unchanged, 'b' is (2, 12)

         // Check everything worked as planned:
         assert(a.x == 1);
         assert(a.y == 2);

         assert(b.x == 2);
         assert(b.y == 12);

         assert(c.x == 6);
         assert(c.y == 12);
     }

Runs without any asserts triggering.
Of course that's just a minimal working type, not how one would 
typically write such a type. For one thing, either make x and y private 
and add setY, getX and getY or get rid of set and setX. For another, 
you'll probably want some more operators (equality, subtraction, maybe 
"multiply by scalar").

Not everything needs to be a class. I see no reason why a type like 
Coord would need inheritance.

> And, I hope that D will have a 'const' type specifier in the future. Now 
> you cannot know if a function will modify an object that is passed to it 
> as a parameter. Or if a member function of a class will change the 
> internal status of the object.

Yes, "const reference" parameters are something D doesn't do, unfortunately.

> When these things are summed together, I'm afraid that I (at least) will 
> create a number of situations where the values of objects are 
> incorrectly changed in almost any part of the code. Hopefully not, though.