Transitive const sucks

[Regan Heath]

Alex Burton wrote:
> While const is being reexamined....
> 
> I create an interface :
> 
> interface Server
> {
>     Data getData() const;
> };
> 
> I then write half my application using a stub implementation of Server, which is refered to using const references, because this application doesn't modify the server (the interface has no non const members).
> Then the time comes to implement the Server properly using a socket to communicate with a server.
> 
> interface Socket
> {
>     void send(const Data d);
>     Data receive() const;
> };
> 
> class ServerImplementation : Server
> {
>     Socket sock;
>     Data getData() const
>     {
>         sock.send(request);
>         return sock.receive();
>     }
> };
> 
> My application doesn't compile because I am refering to using const Server references every where, and it turns out the server class needs to modify it's socket to implement the getData method.
> 
> This is wrong.
> The socket is not part of the ServerImplementation, it's just that D can't tell the difference between things that are part of a class and things that are not.
> I now have to make the getData method non const and all the references to Server non const, and possibly not use any const references in my application again, as similar examples can be constructed for all sorts of things, and basically the const system does not work.
> 
> I think it's great to search for a better const system that c++, but if you have a great system for allowing compiler to optimise, but the programmer can't actually use the system to describe reality then it's not better at all.
> 
> The solution is to be able to say whether the socket is part of the server or not, then the const system can be made to work, as it did in c++.
> I am not saying that c++ const is great but at least I can use it to describe reality (although it's cumbersome, and there are a lot of reasons why I am itching to convert all my stuff to D).
> 
> Sincerely,
> Alex

I remember your example case from your earlier thread. :)

So, correct me if I'm wrong.  You want to be able to specify a reference 
which itself cannot change (perhaps a requirement, perhaps not?), but 
refers to an object which can.  And you want this reference to be usable 
inside a const method.

For the first I would suggest a new syntax like:

class Foo { int a; }
const(Foo&) pFoo;  //pFoo cannot change, pFoo.a can

This is analogous to my other idea[1].

For the second, either:

1. the compiler should assume that as the author used const on this 
reference, and intentionally applied it only to the reference itself, 
that changes made _via_ this reference are not covered by the const 
method contract.

2. we need a new keyword to indicate which references/pointers to 
mutable data can be used in a const method. i.e. "mutable"

in either case you would then be able to make changes to the referenced 
data from within a const method.

[1]See my recent posts to the "Const sucks" thread for the idea that:

class Foo { int a; }
const(Foo*) pFoo;  //pFoo can change, pFoo.a cannot

would declare a tail const class reference.

Regan