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

[Kristian]

On Sun, 10 Sep 2006 18:59:34 +0300, Sean Kelly <sean at f4.ca> wrote:
> Kristian wrote:
>>  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).
>
> Yup.  The .dup property is pretty standard, but there's no convention  
> for whether this should represent deep or shallow copy (though shallow  
> seems to make more sense).

Maybe there should be two properties, .dup and .deepdup (or something,
a name .ddup is probably too similar).


> True.  You can get pretty close, but D does not support an assignment
> operator and there is no universal construction syntax as there is in  
> C++.
> This was a deliberate decision, as handling copyable objects
> in C++ is a common source of bugs.

Really? I mean, a common source of bugs? But isn't it be simple to fix  
such bugs, just correct the copy methods? With references there may be  
bugs much harder to find: an object you're referencing is changed  
somewhere you don't know. You may have to trace a lot of code to find  
where the object gets modified, and correct things around the code, not  
just in one class.

And what if you need copy/clone methods? You implement them by yourself  
(if there is no .deepdub). Using them is not so 'nice' because you can't  
override the assignment operator, etc. These copyable objects are still 'a  
source of bugs', even if used via references, of course.

(And I have to also mention :) that nobody forces you to use copy methods  
in C++. You can use objects via pointers only. But why people don't?  
Because copyable objects suit better in some situations.)


> Currently, you can use a struct or construct a class in place using  
> alloca.  Eventually, we will get a stack allocation syntax for classes  
> along the lines of:
>
>      Coord a = Coord(); // note there is no 'new'
>

Or maybe using a syntax (I have mentioned earlier):

Coord a();


>> 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.
>
> Don't we all.  But wanting it and coming up with a solid proposal for  
> how it should work are entirely different issues, unfortunately.

Well, what's wrong with the way C++ does it?

class Obj {
     void f() const;
     void g();

     int v;
}

void func(const Obj o) {
     o.f();    //ok
     o.g();    //error
     o.v = 1;  //error
}