const

[Oliver Dathe]

Let me first state that I totally agree! As well I'm pretty sure 
transitivity is the exact right way to go.

I think the problem, that people encounter is just the following: 
Usually data is data in process. Therefore it is mutable by nature - 
just no constant. D2 gives the opportunity to declare immutability at 
declarations. Thus it should not be applied to 'data in process' if we 
generally want to avoid unsound operations. This already leaves a large 
/hole/ where people just want to a.) assert, that something they apply 
to their mutable data leaves them invariant but also b.) use a mutable 
result afterwards. Adopting mutable input data by const storage class 
also yields the latter as output. So we've forgotten to remove the lock 
somewhere. You may have to get rid of it by unsound operations.

Currently my suggestion would be some sort of parameter contracts 
[1][2][3] plus (where needed) something that applies the 'const level' 
of a passed parameter to the functions's returntype [4]. I think it 
would not weaken the pro const points 1.-4. but could also avoid 
unnecessary unsound operations that may comprise point 4.

[1][2][3]
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68285
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68248
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68137 

[4] http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf p.38/39

Apart from that: A const property for variables could be a usefull 
thing. e.g. myvar.const would yield a transitive const reference to 
itself - just a shorthand for (cast(const(typeof(myvar)))myvar).