Persistent list

[Jonathan M Davis via Digitalmars-d]

On Saturday, 14 November 2015 at 23:20:08 UTC, Andrei 
Alexandrescu wrote:
> On 11/14/15 5:49 PM, Timon Gehr wrote:
>> It's supposed to guarantee that the given reference is not 
>> used to
>> transitively mutate the object. The casts violate this.
>
> I think that semantics needs to change. Specifically, either we 
> add a @mutable attribute (which means const doesn't apply to 
> fields marked as such and immutable objects cannot be created); 
> or we could just decree that if a const object originates in a 
> mutable object, casts should be well-defined. -- Andrei

Either way, we'd be throwing away the idea that const is physical 
const and provides actual guarantees against mutation via const 
references. We'd essentially be going the route of having C++'s 
const except that it's transitive, which is a definite loss IMHO, 
but at the same time, with D's const, you frequently have to give 
up on using const, because physical const is so restrictive as to 
be unusable in many cases.

I honestly don't know if it's better to just say that you can't 
use const if you want to do something like reference counting or 
using an allocator or to gut the guarantees that D's const 
provides. Ideally, we'd keep the guarantees, but they often seem 
to end up being completely impractical in practice. And they 
don't jive at all with the recent push to support RC.

That being said, if we are going to make a change like this, I'm 
not sure if we even _can_ do it. immutable throws a serious 
wrench in any attempt have something like C++'s const in D.

As it stands, the only thing that really ensures that immutable 
objects aren't mutated is the type system. As I understand it, if 
an immutable object gets put into ROM (or memory that's being 
treated as ROM), then mutating it will cause a segfault, but the 
only case where that might happen right now AFAIK is if the 
object was created at compile time and stored as part of the 
program's data. Certainly, any immutable objects created at 
runtime are only protected from mutation by the type system. So, 
even if the compiler makes _zero_ assumptions based on const, 
casting away const and mutating is very dangerous, because you 
risk mutating an immutable object and violating all of the 
guarantees associated with that. The only time that casting away 
const and mutating could work would be in cases where you could 
somehow guarantee that the object you're mutating is actually a 
mutable variable underneath the hood. That would be possible in a 
restricted setting, but in a large program or in a public API, 
it's a lot less likely that you can guarantee that the object 
isn't actually immutable. There would have to be some way for the 
type system to guarantee that the object isn't actually immutable 
- which either means making it so that the type in question can't 
be immutable for some reason or having an attribute other than 
const for non-physical const.

Your @mutable suggestion/proposal does step in that direction by 
basically making it so that a const type which contains a 
@mutable member isn't really const. It's some other attribute 
that's not explicitly named (cpp_const, logical_const, 
@mutable_const, or whatever we'd want to call it). And that seems 
like it would work to a point. It would even allow for implicit 
casts instead of explicit ones and make the whole thing far safer 
in general than simply allowing arbitrary casting would. However, 
@mutable still isn't an attribute on the type. It's an attribute 
on a member. So, as soon as you have an opaque pointer or a base 
class reference, the compiler doesn't know that the object is 
actually @mutable_const. So, it can't know that it's not legit to 
have the object be immutable. Now, the compiler would have to 
know that when the object is created, and presumably an 
@mutable_const derived class couldn't convert to an immutable 
base class, so maybe this would actually work, but it seems like 
we're at serious risk of a loophole if we're not really careful 
here. It feels like each time work through this I flip-flop as to 
whether I think that it can work or not.

And of course, even if we do make @mutable work, it would 
basically mean that const doesn't necessarily guarantee much of 
anything anymore other than preventing accidental mutation, since 
unless the compiler can guarantee that no @mutable_const is 
involved, it can't assume much of anything about const (though 
what it can assume about const is already pretty limited - 
particularly when pure isn't involved), and programmers can't 
assume that a const object will really not be mutated by const 
member functions (though in practice, it's unlikely that anyone 
is going to slap @mutable on everything). But even then, we'd 
still be ahead of C++'s const if we have transitivity and 
disallow casting away const to mutate.

I'm torn on the whole thing. On the one hand, I think that D's 
guarantees with physical const have been great. On the other 
hand, too much stuff doesn't work with it. And system programming 
stuff like ref-counting, mutexes, and allocators definitely don't 
work with it.

- Jonathan M Davis