mutable, const, immutable guidelines

[Daniel Davidson]

On Wednesday, 16 October 2013 at 18:52:23 UTC, qznc wrote:
> On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
>> Maybe it's helpful to understand how D's const system works. 
>> The
>> following diagram may help (please excuse the ASCII graphics):
>>
>> 	       const
>> 	      /     \
>> 	mutable     immutable
>
> I think people in this thread know how const works, but some 
> think it is broken. Scenario is this:
>

Thanks.

> Library code:
>
> struct Foo { int x; }
>
> User code:
>
> Foo f;
> immutable f2 = f;
>
> This works, even though the library writer might not have 
> anticipated that someone makes Foo immutable. However, now the 
> library writer obliviously releases a new version of the 
> library, which extends it like this:
>
> struct Foo {
>   int x;
>   private int[] history;
> }
>
> Unfortunately, now the user code is broken due to the freshly 
> introduced mutable aliasing. Personally, I think is fine. Upon 
> compilation the user code gives a  error message and user 
> developer can adapt to the code to the new library version. 
> Some think the library writer should have a possibility to make 
> this work.

I don't understand how it could be fine. As code grows it would 
lead to people not adding useful members like history just 
because of the huge repercussions.

struct User {
    immutable(Foo) foos;
}

How can I as a user adapt to that change? Before the change 
assignment worked equally well among all of Mutable, Immutable, 
Const. After that change any `foos ~= createFoo(...)` would 
require change. And it is not clear what the change would be.