Logical const

[Steven Schveighoffer]

On Thu, 02 Dec 2010 12:59:22 -0500, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 01/12/2010 21:09, Steven Schveighoffer wrote:
>> On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> If you find the above unsurprising, you are in the minority. I find
>>>> it surprising, and invalid that anyone would write code this way.
>>>> People simply just don't do that normally. It's just written to
>>>> demonstrate a point that the compiler does not guarantee anything via
>>>> const, it's guaranteed by convention. The compiler simply helps you
>>>> follow the convention.
>>>
>>> Ok, I see what you mean now. Your code is relying on there being a
>>> mutable alias of the same object.
>>>
>>> This is not surprising behavior. It is explicit in how const is
>>> defined. It makes sense that const does not have immutable behavior,
>>> because otherwise there wouldn't be both const and immutable type
>>> constructors.
>>>
>>> You're wrong in saying the compiler doesn't guarantee anything with
>>> const. I listed the things it does guarantee.
>>
>> The literal guarantee is that things aren't modified through that
>> reference.
>
> So now you do agree that (D's) const does provide guarantees, right?

It guarantees something very focused, and possible to work around without  
resorting to unsafe code.  That's my point.  The guarantee is well-defined  
and useful because it helps write correct code, but I don't see how a  
logical const guarantee is mythical whereas D's current const guarantee is  
impermeable.

I have shown examples of how const does not guarantee an object's state  
doesn't change.  It's some work to make it happen (which is good), but  
'guarantee' is too strong a word in my opinion.  I'd say it's a tool that  
helps you follow a good convention, just like logical const would.

-Steve