Persistent list

[Joseph Cassman via Digitalmars-d]

On Monday, 16 November 2015 at 06:24:05 UTC, Jonathan M Davis 
wrote:
[...]
>
> Regardless, I think that it's quite clear that certain idioms 
> simply do not work with physical const, and there's been 
> complaining about that for years. The only real question here 
> is whether those idioms are worth enough to lose out on 
> physical const. The answer up until now has always been no (at 
> least from Walter), but since Andrei is now hitting this 
> himself rather than seeing others complain about it, he clearly 
> views it as a problem in a way that he didn't before, so that 
> may result in him changing Walter's mind.
>
> - Jonathan M Davis

I appreciate this discussion. I feel better that I am not the 
only one having difficulty with the _const_ keyword. Honestly 
about the only time I use _const_ is to tell the D compiler that 
a struct member function does not modify its containing type. 
When I start to use _const_ I quickly get a headache trying to 
figure out how to fix my code when the compiler starts to 
complain about function overloading issues and starts to require 
explicit casts all over the place, _inout_ doesn't work, did I 
use _Unqual_ or maybe I shouldn't, should this be a template, 
etc. I end up with a headache and all I want is the thing to 
compile. I wonder many times why go through the trouble. Why not 
just use a unit test?

After reading through this discussion I wonder if it has been 
considered to keep _immutable_ and _const_ as they are, but add a 
less restrictive do-not-change-me type qualifier to the language? 
A keyword like _readonly_, for example, could represent the idea 
of intransitive const (or perhaps even a different type of 
do-not-change-me-ness). I appreciate the need to be conservative 
in language additions, especially at this point in the life cycle 
of D2. Still, if people want and can show they need a type of 
do-not-change-me type qualifier in addition to _const_ and 
_immutable_ (not overlapping with unique et. al.) why not provide 
it for them?

Just as a side thought, although it is probably a bit of a 
dasoku. But I have always wondered that if the purpose of _const_ 
is to allow some data to be changed by one reference but not 
changed by another, then why is it transitive. Doesn't that 
defeat its purpose? And then doesn't transitive const effectively 
have the same semantics and use-case as _immutable_? I mean, once 
you start to use transitive const in an interface, how are you 
supposed to get the mutable reference that is so promised? 
Perhaps this is the question that is essentially being asked here?

Joseph