What does C++ do better than D? - StackOverflow.com

so so at so.so
Tue Aug 2 07:41:13 PDT 2011


On Tue, 02 Aug 2011 14:17:29 +0300, person <person at 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

> 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.

> 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.


More information about the Digitalmars-d mailing list