[boost] Re: is_convertible corner case

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-26 06:49:11

On Sat, 25 Jan 2003 19:17:35 -0500, David Abrahams
<dave_at_[hidden]> wrote:

>It's hard for me to justify any other interpretations under a strict
>reading of the standard.

Yes.

>I am tempted to open a DR about this, but
>I'm not sure exactly how much we should ask for.  Shooting for the
>moon, we could ask that an expression can only invoke undefined
>behavior if it is "potentially evaluated", c.f. 3.2/2

That solves the problem when you wrap the function call in a sizeof;
but leaves undefined behavior for Peter's example, where the call is
never performed. I would say that one should allow undefined behavior
only if the call is actually executed (I should rather say: when the
call-expression is actually evaluated, to take into account inlining.
But I'm trying to use a simpler language). Basically I find that the
standard is all but crystal clear when it comes to the difference
between a function-call expression (banally: a sequence of "signs"
written in the program text) and a function call in its run-time
meaning. Take for instance the beginning of 5.2.2/4:

   "When a function is called, each parameter (8.3.5) shall be
   initialized (8.5, 12.8, 12.1) with its corresponding argument.
   When a function is called, the parameters that have object type
   shall have completely-defined object type."

It uses the phrase "When a function is called" two times: in the
second case it clearly refers to the function call expression, not to
the actual call of the function; so the "when" is to be interpreted as
"at the point of". In the first case I tend to think instead that it
refers to the run-time call, because initialization of function
parameters (as I intend it) is a run-time operation. Note in fact
that, immediately after, the standard says:

   " **During** the initialization of a parameter"

IMHO trying to think initialization as a purely formal (and thus
compile-time) operation is a little problematic. Coming back to the
main point, I think that if the standard was more clear in the
distinction between a call and a call-expression we wouldn't have any
chance to ask ourselves whether

   f( non_pod );

is undefined or not: either the standard would say that writing the
function-call expression is undefined (thus even if it is in a
sizeof), or that actually calling the function is undefined.
Personally, I think it should be the second one and that Peter's
example should have a well-defined behavior.

Genny.