Persistent list

[Dicebot via Digitalmars-d]

On Saturday, 14 November 2015 at 21:02:46 UTC, Observer wrote:
> On Saturday, 14 November 2015 at 16:27:17 UTC, Dicebot wrote:
>> All trouble comes from trying to use physical immutable as 
>> logical one while still pretending it gives physical 
>> guarantees. Even if existing immutability is not widely 
>> applicable, I'd prefer to have narrow applicability over wide 
>> false confidence. Right now I know for sure that if I can use 
>> immutable data without any thread locking and it is not 
>> possible to screw it up. It is rarely important, but when it 
>> is, it is priceless.
>> I can't say I'm following this discussion in great detail, but
> one thing strikes me.  "const"-ness and "immutable"-ility are
> at some abstract level flavors of value stability.  And that
> suggests to me that perhaps we should not be looking so much
> for backdoors as for new terms, leaving the old terms alone.
> Perhaps a given old keyword won't work well with RC; so be it.
> Perhaps a new keyword such as "stable" could be used to describe
> a storage category where the payload fields are unchanging but
> any metadata fields are potentially mutable.  Then perhaps const
> could mean physically immutable, while stable means logically
> immutable.  Or something like that.

I simply don't see much value in logical immutability (and only 
small value I n logical const). Recently I had experience of 
porting lot of D1 code (which had const as a storage class) to D2 
and was surprised how fake most of added safety seemed. In most 
case modifying such value wouldn't cause any trouble at all and 
case for real trouble comes from subtle indirectional mutation.

Because of that I am very unhappy with attempts to break the type 
system which had costed considerable part of limited language 
resource for the sake of fake convenience (all @mutable 
speculation)