mutable, const, immutable guidelines

[qznc]

On Monday, 7 October 2013 at 17:57:11 UTC, Ali Çehreli wrote:
> To look at just one usage example, the following line carries 
> two requirements:
>
>     auto a = T();
>     immutable b = a;
>
> 1) b will be an immutable copy of a.
>
> 2) T will always be usable as in that fashion.
>
> If T appears on an API, it is the responibility of the user to 
> ensure whether they are allowed to treat T in that way. 
> Otherwise, they risk maintainability if the module decides to 
> change T in any way that fits the module's needs. If they have 
> not yet advertised that T can be used as immutable, it should 
> not be.

I do not agree with you, that the user has the responsibility. 
Rather I think the provider of T has the responsibility to 
maintain backwards compatibility. My principle is "anything is 
allowed, unless explicitly forbidden". This includes immutable 
type constructing. It is great that we get a type error, if 
backwards compatibility is broken.

Nevertheless, the question of responsibility seems to be 
subjective. Are there any clear technical reasons for either way?

Unfortunately, there is no way for the provider to allow or 
disallow immutable(T). Maybe there should be a UDA or something 
for this?