🚀 go-pugleaf

> "ian (i.) willmott" <willmott@bnr.ca> writes:
>> It seems to me that this example tends to indicate that the prohibition of
>> non-const references to rvalues is a bad idea, at least for function
>> parameters. Section [basic.lval] suggests that you can in fact call a
>> non-const member function on a temporary object, so it's also inconsistent
> .
>> Why distinguish between member and non-member functions in this respect?
> 
>> Surely there is a whole class of situations like this where the destructor
>> for a temporary has side effects which you may want to avoid or change by
>> modifying the object before it goes out of scope. I'm not sure what the ARM
>> means by "a major source of surprises"; if you pass a temporary as a
>> reference parameter, it's obviously going to evaporate after the function
>> returns, no matter what the function does or doesn't do to it.

kanze <kanze@lts.sel.alcatel.de> writes:
> The surprise occurs when you `accidentally' pass a temporary, such as the
> result of an implicit conversion.  Consider the following:
> 	void incr (int& i) {i ++;}
> 	unsigned j (0);
> 	incr (j);                   //  j unchanged!!!
> 
> I suppose the best rule would be to simply ban implicit conversions, and
> make the programmer say what he means.  But I rather suspect that the amount
> of code that this would break will prohibit any such change.

There is a perfect solution which I would be happy if someone proposed
officially.  It prevents the above pitfall, yet it allows temporaries to be
modified.  Also, it breaks no code since (I think -- check me out on this) it
merely relaxes the rules:

- First of all, get rid of the worse-than-useless restriction that disallows
binding non-const references to temporaries.

- Second (and last), add a rule that says that there is no implicit conversion
of a temporary to a non-const reference.

The intent of the currently existing rule is to prevent code from mistakenly
modifying the result of an implicit conversion instead of modifying the
original object.  This pitfall is the only reason I know of for prohibiting
functions modifying temporaries.  Witness the fact that the prohibition does
not extend to temporaries invoking non-const member functions since implicit
conversions are not done to objects invoking member functions.

The above proposed changes will still prevent this pitfall, by preventing the
implicit conversion to a temporary rather than preventing the binding of a
temporary.  The new rule will allow temporaries to be modified, which is
important to many designs, including auto_ptr<>.  And these changes will not
break existing code, since they only disallow the implicit conversion when the
resulting binding would be disallowed under current rules.

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]