[C++ dayly bug report] const_cast to rvalue of class type

[Benjamin Scherrey]

Gabriel Dos_Reis wrote:
> 
> Benjamin Scherrey <scherrey@switchco.com> writes:
> | ...  I still don't believe that it was their intent to
> | limit the const_cast as you say at all.
> 
> Can you give evidence to support your claims? Did you read 5.2.11/12?

	Huh? My evidence is that you made a claim and I expressed my opinion
that it was not their intent. I made an opinion, not a claim. Obviously
I read the relevant sections because I quoted parts of them to you.
 
> | ... Can you tell me why this
> | limitation would be meaningful? I don't see anything gained by it.
> 
> That is an interesting question. I wasn't yet on the committee when
> the decision was made and can't report what were the pros. Anyway, you
> can still ask in comp.std.c++.

	I'm getting the impression here that your interest is more in language
lawyering than in producing a usable and correct language standard. My
experience, thus far, is that when you find an issue in the written
standard that seems unusual, you can usually figure out why they came to
that position (either because of previously stated and remarkable well
met overriding language goals or they come out and tell you) or else it
is simply a mistake. Believe it or not, we've run across a couple.

	Now the issue we're dealing with here is one that seems rather obvious
at first glance. These are exactly the ones that get us in trouble! In
this case I'm trying to think of a reason for the limitation the text
seems to present and I am at a loss to uncover one other than there
isn't a lot of point in doing it because most uses will simply generate
a copy constructor call in which case its const'ness becomes irrelevant.
Given that, and the fact that the related language feature, dynamic_cast
(which has these expressed limitations) goes out of its way to state
this limitation (and justifiably so), I live under the impression (quite
possibly incorrectly) that the text is in error or just so really
unclear as to be indecipherable.

	Now you've come on this mailing list and made an apparently justified
assertion. You've also made a request that this "mistake" be corrected
in the compiler. In response, at least one other person as well as
myself (of which I doubt either of us will be involved coding the "fix")
have provided practical answers to your issue with the desire (which we
assume you share) to learn from and clarify this enormous document. As a
response you seen only willing to provide theoretical arguments and no
practical justification for your request.

	I suggest to you that this mailing list has a priority for practical
issues. There is a very long list of practical and large impact items
that the egcs developers must address before consideration is given to
minute standards compliance with no defined benefit. Therefore I
recommend that you take your question to comp.std.c++ yourself and see
if a practical justification can't be identified or, barring this
eventuality, that you submit the text as an error for the standards
committee to clarify. If a practical justification is found, please let
us know so it can be listed as an issue and put in its proper priority
on the things-to-do list.

	regards & later,

		Ben Scherrey

... who, after considering, debating, and berating this issue,
anticipates some compiler genius to provide the "but of course" reason
for said const_cast limitation! :-)