const challenge

[Walter Bright]

Steven Schveighoffer wrote:
> I think it is unreasonable for the compiler to restrict code from compiling 
> because someone might change an API or implementation in the future.  It is 
> always possible to break code in the future by changing an API or type.  Why 
> should a developer who is certain that the type will never contain a pointer 
> be punished because the compiler can't predict what he will do with the type 
> in the future?  What if someone does add a pointer to vector, then other 
> pieces of code that expect copying a vector to make a 'deep copy' will 
> break.  I understand the concern, but I just don't think your argument is 
> valid.  Also, having this restriction makes it impossible to mimic builtin 
> types with struct wrappers, as builtin types already enjoy this benefit.
> 
> The real question is, is it possible for the compiler to determine whether a 
> type contains pointers, and if so, restrict copying const or invariant 
> versions of the type to mutable types.  I believe the answer is yes, 
> although the compiler doesn't take that into account today.  I even think 
> that it is strictly a compile-time check and therefore should not affect any 
> existing code.
> 
> If this is the case, the next question is, why would it be undesirable to 
> have this behavior?  I have not yet seen a good answer to this.

Your argument is sound, and I agree with it. I think it's pretty clear 
this will have to be changed.