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.
