Hmm - about manifest/enum

[Steven Schveighoffer]

"Janice Caron" wrote
> On 1/2/08, Steven Schveighoffer wrote:
>> That anyone got persuaded that something is wrong is not proof that it is
>> wrong.
>
> Unless I have misunderstood some step of the reasoning, every scheme
> to allow mutable-reference-to-const-class-data which has so far been
> proposed has been proven unworkable. The same logic should lead you,
> or anyone else, to the same conclusion.
>
> Of course, this is not a proof that there is /no/ solution, only that
> the suggestions made up to this point all have fatal flaws.

I highly contest this statement.  I have never seen any statements that my 
proposal (dated 12/7) proved unworkable.  In fact, Walter completely ignored 
it.  The assumption you are making here is that because Walter didn't 
consider a possibility proves it's unworkable.

>> "this leads to different problems" is not an explanation.
>
> Of course not. I'm hardly going to condense six months' worth of
> patient reasoning into a single sentence. You're proposing something
> which has already been proposed before (by me, as it happens), and has
> been shown not to work.

I've been through that also :)  I read through all the 'const sucks' and 
'const again' and all those proposals.  I have not yet seen proof that all 
solutions are unworkable.  It seems like (seems like, not is) Walter has put 
considerable thought and effort into trying to get tail const for class 
references to work, and could not form a solution that was reasonable. 
Therefore, he concluded it was not possible, and for some reason, will not 
even consider new ideas.

>> If C isn't a reference type, then it doesn't compile.
>
> That was my suggestion too. In the thread "const again", I said "I had
> in mind that that would be a syntax error", to which Walter replied "A
> special syntax for class types means that one has to know that type T
> is a class." And this is the flaw here: It must compile without
> knowing what T is.

Again, this inconsistency already exists today!  The inconsistency stems 
from the fact that classes ARE reference types.  There is no way around 
having to know that.

If you do:

setValueTo5(T)(T x)
{
   x.value = 5;
}

If T is a class, then it affects data outside the function.  If T is a 
struct, it does not.  We have to know if T is a class or not.

My counter-argument is "yes, it's inconsistent, but not any different than 
what we have today, how is this any worse?"

In fact, I believe the only way to make it consistent would be to make 
classes value types (which I believe is a bad idea).

-Steve