On Thursday, 17 October 2013 at 19:17:38 UTC, Daniel Davidson
wrote:
True and I believe they do it without an immutable keyword.
They do, but it's a special case, as opposed to D.
I'm not questioning the value of a non-mutable type, just
trying to get to the heart of why the keyword immutable is
preferred over const in this example.
As Dicebot said, NOBODY can modify immutable, while they can
modify const. YOU are the only one that can't modify const. It
could change right under you at any time.
Dicebot clarified it - essentially it is because sharing can
creep in before it gets settled into a const(char)[] context.
And once sharing has potentially happened you can't undo it
except for transitive deep copy.
Had D gone with:
struct String {
const(char)[] s_;
this(char[] s) { s_ = s.dup; }
}
and not allowed any modification of elements you would still
have immutable without the keyword. Granted, it would not be
efficient so I see the benefit.
That'd be a special case like in other languages, which isn't
necessary in D because of immutable.
Strings/slices have sharing. Can the same issue/benefit occur
with primitives? Would you ever have a need for
`immutable(int)` over `const(int)`?
Only if there's indirection, e.g., int vs. pointer to int.