Head Const

[Jonathan M Davis via Digitalmars-d]

On Friday, 19 February 2016 at 12:03:01 UTC, Walter Bright wrote:
> On 2/19/2016 3:21 AM, Jonathan M Davis wrote:
>> D is definitely in a better boat in that it's easier to find 
>> and catch problems
>> with const, but it really doesn't do much more to actually 
>> guarantee that a
>> const object isn't being violated. Programmers are free to do 
>> horrible things
>> and mark it as @trusted,
>
> The point of @trusted is it can be grepped for, and undergo 
> extra scrutiny. The idea is to minimize @trusted sections. With 
> C++, it's the WHOLE PROGRAM that has to be scrutinized.
>
> This is ORDERS OF MAGNITUDE different.

Yes, as long as you have the source code, finding @trusted 
violations is _way_ easier in D than it is in C++, but the fact 
that it's possible to cast away const and mutate still means that 
the compiler can't actually guarantee that an object is not 
mutated via a const reference to it. It can just guarantee that 
so long as @trusted code behaves itself. So, that's an enormous 
improvement, but it still means that it's possible for you to 
pass an object to a function that takes its argument by const and 
end up with that object being mutated by that function - and 
without you knowing about it unless you go digging through the 
code for @trusted violations.

But even if the compiler completely succeeded at guaranteeing 
that an object is not mutated via a const reference, there's the 
problem that because D's const is so restrictive, a lot of D code 
ends up not using it, which means that it gets _zero_ benefit 
from const, whereas in C++, it would have been const, and const 
would have caught some bugs even if it didn't provide strong 
guarantees. So, the code that could have used const in C++ but 
can't in D suffers because it doesn't even have partial 
protection by const. It's only the code that doesn't need 
something like the mutable keyword and which doesn't need to 
interact with code that needs something like the mutable keyword 
that can benefit from D's const. For instance, very little 
generic code in D is able to mark its parameters as const even if 
it doesn't mutate it, because there's a high chance that someone 
is going to want to be able to use that function with a type that 
won't work with const.

So, I think that even if D's const is far better than C++'s where 
it does work, we're actually worse off than C++ in a lot of code, 
because there are a lot of places in D where it doesn't work, and 
we can't use const, whereas the same code in C++ could have. So, 
we end up with no protection instead of partial protection, which 
is not an improvement. It's like we've come up with tank armor to 
protect people from bullets, and we won't let anyone wear bullet 
proof vests anymore, because they're not as good as tank armor, 
and so the folks who can't do their jobs behind tank armor are 
screwed when the bullets come.

>> I'm proposing that we have something like
>>
>> @mutable struct S
>> {
>>      int i;
>>      @mutable int* refCount;
>>      ...
>> }
>
> This does not work for opaque types.

Why not? I would expect the opaque type to have to have it too, 
e.g.

     @mutable struct S;

and that if it didn't, it wouldn't be compatible with the full 
type definition. But maybe I'm missing something with opaque 
types, since I don't use them much, and I don't think that I've 
ever used them in D. But the whole idea of putting @mutable on 
the type definition itself instead of just on the member variable 
was that opaque types would have to have it too and that seeing 
the @mutable members would not be required to know that a type 
contained @mutable members.

- Jonathan M Davis