D const design rationale

[BCS]

Reply to Martin,

> After reading the articles by Walter referred to recently, I'm less
> confused that I was, but would still appreciate some further
> explanation.
> 
> So should "const foo bar = baz" be an error if foo is a value type, on
> the basis that one should be using "invariant" or maybe final? It it
> safe to have two things const/invariant that become identical
> depending on type?
> 
> And does "final" exist *solely* so that you can approximate
> "invariant" for objects as well as for structs and scalars? I can see
> its use when you want something to be invariant but with the
> stipulation that it must exist in memory and have an address. In which
> case, why have final vs invariant at all, rather than having final be,
> for example, "weak invariant" or "stored invariant" or something like
> that? From here, final just looks *semantically* like "a poor man's
> invariant".
> 

One use of final that I can think of is this (assuming I understand correctly)

int foo(final int* bar)
{
}

bar now acts like a c++ reference (can't be pointed to something else) but 
with the syntax of a pointer.