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

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:


[...]

| > | ... 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.

Actually your impression is wrong. 

| ...  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.

Well, I've suggested that your ask your ask about the 'rationale'
behind const_cast ono comp.std.c++, because at the first place that
newsgroup is the right place to ask such a question. I do beleive that 
this list is about practical questions related to implementations of
the various standards EGCS attempts to implement, including C++; I
don't beleive this is the right place to discuss rationale behing
allowinf or fordiding something in C++. Nor do I beleive this is the
right place to start flames.

| 
| 	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.

The answers I provided weren't theorical. Beleive it or not. On this
list my primarily goal is to contribbute to a usable compiler,
reasonably conformant. The bug I reported was already reported a while 
ago and wasn't fixed. It just happened several people --pratical
programmers for that matter--  who are annoyed by that bug asked me
for a fix. Martin and Mark recognized the bug and Mark provided a
fix.

| 	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.

I will ignore this gratituous flame and direct you to libstdc++ in
case you doubt my *pratical* involvement on EGCS. 

-- Gaby