Proposal for scoped const contracts

[Steven Schveighoffer]

"Steven Schveighoffer" wrote
> I have found there are more issues that my solution doesn't solve exactly, 
> so these need to be figured out.
>
> For example, a linked list of mutable classes might be a template defined 
> as:
>
> LinkList(T)
> {
>   void append(T t) {...}
> }
>
> for the append function, the t argument is not modified during the 
> function, but the link list node added should be not const.  So if a 
> LinkList node is Node(T), then how do you write the signature and body of 
> this function?  Is it important to declare t as an 'in' parameter?  I'm 
> almost thinking that there is no real way to have the compiler be able to 
> prove that an argument is not modified for all types of functions.
>
> In addition, going back to the same example, append should only accept a 
> mutable object for t, otherwise, it cannot construct a proper node to add 
> to the list.  So how is this information communicated to the compiler?  If 
> we use:
>
> void append(in(T) t);
>
> Then a const or invariant t could be passed to the function, which would 
> be no good.
>
> Is this even a concern that we should worry about?

This is a great case of over-analyzing :)

I now realize that this is a non-issue, because the append function cannot 
use an in modifier for t, because t might be modified later as a result of 
it being added to the list through append.  So append should not be 
modified.

I think this whole scheme should really be restricted to returning a subset 
of a given input type, not building something out of the input type.

-Steve