Why do "const inout" and "const inout shared" exist?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 3 July 2017 at 15:48:26 UTC, Petar Kirov [ZombineDev] 
wrote:
> Unlike C++, in D objects can't be shared across threads, unless 
> they are marked as `shared` (modulo un-`@safe` code - like

I understand the intent, but since everything is "shared" in C++, 
unless you annotate variables with optimization-constraints, it 
doesn't make sense to compare C++ const to D const. One should 
either compare C++ const do D shared const, or compare C++ 
const-with-constraints with D const.

> int foo(const(int)[] array) pure
> {
>     // globalArray[0] = 42; doesn't compile
>     // For all intents and purposes, the elements of `array` can
>     // be viewed as immutable here and they are *not* aliased.

They aren't aliased because you only have one parameter with 
non-reference values. That's a rather narrow use-case…

> I've watched a presentation on Pony's type system and it is 
> indeed interesting,

Yes, e.g. Pony have "isolated" (e.g. no aliasing) with 
transitions to less constrained types.

> but can you explain exactly what part of Rust's type system 
> provides extra
> benefits in terms of optimization over D's type system?

As I understand it Rust's static analysis is designed to track 
aliasing using linear/affine typing for objects.