Throw a reference and assignment-expression in throw-expression

{ Please limit your text to fit within 80 columns, preferably around 70,
  so that readers don't have to scroll horizontally to read each line.
  This article has been reformatted manually by the moderator. -mod }

I was browsing through the Standard (N3337 in this case) to refresh my
knowledge about exceptions and throwing in particular. And there is
something that I???m unable to understand. In 15.1$3 there is:

??A throw-expression initializes a temporary object, called the exception
object, the type of which is determined by removing any top-level
cv-qualifiers from the static type of the operand of throw and adjusting
the type from ???array of T??? or ???function returning T??? to ???pointer to T???
or ???pointer to function returning T???, respectively. The temporary is an
lvalue and is used to initialize the variable named in the matching
handler (15.3). If the type of the exception object would be an incomplete
type or a pointer to an incomplete type other than (possibly cv-qualified)
void the program is ill-formed. Except for these restrictions and the
restrictions on type matching mentioned in 15.3, the operand of throw is
treated exactly as a function argument in a call (5.2.2) or the operand
of a return statement.??

Now the question is what about references? Consider code (lets skip any
???design issues???):

int& get_object() {
    static int var = 0;
    return var;
}

void f() {
    throw get_object();
}

What gets thrown by f() is an object of int type that has nothing to do
with get_object()???s var except for the initial value at the throw moment.

While according to how I understand the cited fragment the static type of
throw operand is here int& rather than int. So the temporary exception
object should be int& rather than int. And thus should be a reference to
actual get_object()???s var rather than a copy of it.

It is obvious that my understanding of the cited fragment is just wrong.
But why? Is there something else that I don???t see? Or did not follow
references thoroughly enough?

Is this about the last fragment ???the operand of throw is treated exactly
as a function argument in a call (5.2.2) or the operand of a return
statement???? I didn???t get it (at least in this context). If this somehow
explains why the above code doesn???t throw int& then please explain it to
me in more details.

Also I considered that maybe answer is in the throw operand expression.
It is marked as assignment-expression_opt. But tracing that not only
didn???t help but actually caused more confusion.

assignment-expression seems to be defined at 5.17$1. I fail to see there
anything that would prevent throwing int& rather than int.

And now the confusion. According to that definition assignment-expression
could be a??? throw-expression. So we have (for example):

throw-expression ??? throw assignment-expression_opt ??? throw throw-expression
??? throw throw assignment-expression_opt ??? ???

and yet it is quite easy to see that the above construction (throw throw ???)
does not compile. Reported error is that void expression is used for throw
(the external one). A justified claim, however we know that this would
never arise as an issue since the external throw will never have anything
to throw, evaluation of the expression will throw by itself.

So it seems that assignment-expression in throw-expression must not be
just any assignment-expression. There are some which are not allowed. In
fact any such expression that is of void type will cause compiler error.
(Possibly others as well.) Sure, 15.1$3 does say that incomplete type
cannot be used (and void is an ???incomplete type??? according to 3.9$5). But
given ???grammar??? allows it (while with some extra rules it could exclude at
least the throw-expression case) and Standard ignores the fact that a
throw-expression is ???no return??? one thus its type is of no importance.

In the end some side note. Wouldn???t it be better if 15.1$3 excluded
throw-expressions without operand? Otherwise reader must get to 15.1$8
to see that what he read in 15.1$3 doesn???t apply to this case. (It seems
to me that even reordering those rules so that the no-operand case is
described first would also be better than current state.)

Adam Badura

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]