🚀 go-pugleaf

In <47ec58$3t3@meg.tesser.com>, ralphs@tesser.com (Ralph Shnelvar) writes:
>
>kanze <kanze@lts.sel.alcatel.de> wrote:
>
>>The surprise occurs when you `accidentally' pass a temporary, such as
>>the result of an implicit conversion.  Consider the following:
>.. . .
>>
>>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.
>
>Yesterday, on compuserve I said almost exactly the same thing.
>
>Let there be a #pragma or -something- that turns off this awful
>creation of temporaries.
>
>Ralph

Perhaps the *best* rule would be one that permits the initializer for a
non-const T& to be *any* object of type T, not just lvalues?  It seems
there's a clear distinction between these three cases:

    void incr( int& ); 

    int    ok();
    double notOk;
    double maybe();

    incr( ok()  );   // This is OK.
    incr( notOk );   // This isn't.
    incr( maybe() ); // Why not?

In the first case, the reference is clearly bound to the same object that
the programmer specified as the initializer.  In the second, the reference
is clearly bound to a different object.  In the third, it's a different
object but I don't think it much matters.

I would like to see a rule that prohibits only cases where the binding of
the reference requires the conversion from a non-temporary initializer
to a temporary object.  At the least, I think it should be OK if no
conversions are required.

In other words, is it possible the baby was thrown out with the bathwater
when the "notOK" problem was fixed way back when?  Or is there no way
(syntactically or otherwise) to loosen up the rules just a little?

Bill Law
---
[ 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. ]