WTF did happen with struct constructor and ref in 2.061 ?

[Ali Çehreli]

On 01/05/2013 11:34 AM, Maxim Fomin wrote:
 > On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:

 >> >>> There is no semantic difference between
 >> >>>
 >> >>> S s = S(2); foo(s)
 >> >>>
 >> >>> and
 >> >>>
 >> >>> foo(S(2));

 >> Still, there is no semantic difference.

 > Why do you think there is no semantic difference?

I took the example with an assumed scope around the first line:

     { S s = S(2); foo(s); }

That's why all I see is that an S object is constructed and passed to 
foo(). Same as the following:

     foo(S(2));

 >> Constructors and functions do not affect objects alone. However
 >> frowned upon, a function that is called on an S may have side-effects
 >> that are beyond the object itself. If foo() does s.bar() and S.bar has
 >> a side-effect, I wouldn't care about the changes on the rvalue object
 >> itself.
 >
 > Even if one particular function makes some side effects and does not
 > care by taking ref parameter that changes may be discarded, it is a
 > source of bugs in general, when taking argument by ref means that passed
 > object must be modified and changes need to be preserved.

I agree that perhaps a number of my bugs have been avoided by that. I 
still find it too intrusive of the language when it assumes that the 
changes to the object are important as well.

Yet, the language has no interest in e.g. the return values that may not 
be consumed completely:

     vector<int> v = makeVector();
     cout << vector[0];
     // Oops! Have I forgotten vector[1] or did I simply not care?

I see it the same issue with ref parameters. foo() may call 
s.nonConstFunc(), which may have two effects: A side-effect and a 
modification to the object. Why would I not be allowed to not care about 
the latter similar to how I did not care about vector[1]? That's my point.

Again though, perhaps this rule has protected me more than it brought 
inconveniences.

Ali