how would D be different if string were const(char)[]?

Meta jared771 at gmail.com
Thu Oct 17 16:35:38 PDT 2013


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.


More information about the Digitalmars-d-learn mailing list