== Quote from so (s...@so.so)'s article
> On Tue, 02 Aug 2011 14:17:29 +0300, person <per...@email.com> wrote:
> > The problem as I see it is that D has two separate concepts that are
> > conflated:
> > const and immutable. In fact, I'd argue that immutable shouldn't even
> > exist in its
> > current standalone state but should rather be part of an ownership
> > system a-la
> > Bartosz' suggested annotation system.
> The way const and immutable work in D is something essential, one is
> mostly useless without the other.
> I think people have a few misconceptions regarding how they work.
> fun1(const Bar b1); // you can pass both mutable and immutable, but after
> you enter here it treats "b1" just like fun2 treats its argument "b2".
> fun2(immutable Bar b2); // you can pass only immutable
I know how const/immutable currently works in D. I was suggesting it has
problems.
> > In the context of single threaded programs const mustn't be transitive.
> > E.g.
> > class Foo { int a; ... }
> > class Bar { Foo foo; ...}
> > void func(const Bar b);
> > void gunc(immutable Bar b);
> >
> > func should be able to change b.foo.a but not b.foo (foo is head-const
> > or "final")
> > gunc however will enforce transitivity and will not allow to change
> > b.foo.a
> Wouldn't that be just going right back to C++ const system, (well i think
> it is also what you want)?
> Also the main purpose of const in D is providing a immutable environment
> for both mutable and immutable types.
I'm not suggesting going back to C++ (which sucks). I'm suggesting that
handling an immutable environment in D should be different.
> > In the context of multi-threaded programs, casting const(T) to an
> > immutable(T)
> > would require locking/synchronization in order to preserve correctness.
> >
> > To conclude, Instead of D's current model where both T and immutable(T)
> > can be
> > "up-casted" to const(T) I'm suggesting
> > T -> const(T) -(locked)-> immutable(T)
> >
> > In addition, compile-time "manifest" consts via enum should be removed
> > in favor of
> > immutable.
> AFAIR that wasn't possible, enum states it is a compile time constant
> unlike immutable.
> I think we should drop const in our discussions when we mean immutable.
> Its use in C++ is too broad and sometimes not applicable in D.
enum is a *hack* required only to circumvent the current linker.
There is nothing in the language design that requires this. The /correct/
solution
would be to use immutable and let the tool-chain figure out that memory is only
required if you take the address of that immutable.
