Logical const

[Steven Schveighoffer]

On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 02/12/2010 21:04, Steven Schveighoffer wrote:
>> On Thu, 02 Dec 2010 13:57:04 -0500, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail> wrote:
>>
>>> On 29/11/2010 14:56, Steven Schveighoffer wrote:
>>>> This has been discussed at length on this newsgroup, and I argued for  
>>>> it
>>>> for a long time. You will not get any traction with Walter, because
>>>> I've already proven that logical const == const, and it still doesn't
>>>> change his mind.
>>>
>>> Could you detail a bit what do you mean by logical const == const ?
>>> That doesn't sound right to me.
>>>
>>
>> Here is where I show how logical const already exists, it's just clunky
>> to use.
>>
>> BTW, this was before TLS, so the example would have to be updated a bit.
>>
>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58927
>>
>>
>> -Steve
>
> Ok. Well, for starters the "const" functions that mutate the object  
> state cannot be pure. (if you manage to mutate it without casts in a  
> pure function, it's because of a compiler bug)

Yes, pure requires special handling.  I believe that mutable-marked  
members of an object should not be considered part of the object, just  
related to the object.  So it would make sense to disallow access to those  
members in pure functions when the objects are const or immutable.  It  
would at least make the semantics the same as logical const is defined  
here.  When the object itself is not const or immutable, I think possibly  
access to the mutable members should be allowed, but I haven't worked  
through the details in my head yet.

> Second, there's the TLS thing. I don't think you can just "update it a  
> bit", there would be significant changes, maybe not in code size, but in  
> runtime effect: You would need to make it global shared, and thus have  
> to synchronize the access to the _mutable global. This is quite  
> significant.

I actually re-read the code and realized that it should work without any  
changes (sans the issue you bring up below with implicit sharing of  
immutable).

> The above are not trivial differences, so I do not agree that it  
> constitutes full logical const, only a limited form of it. More  
> concretely, it doesn't constitute logical const in in the sense where  
> you can use that as argument to say "logical const already exists, it's  
> just clunky to use", so let's add it to the language formally. Like if  
> mutable members where just syntax sugar, or a betterment of safety rules.

I disagree, I think it does prove logical const already exists.  How do  
you define logical const?

> There is one thing however that doesn't feel right in all of this, with  
> regards to passing immutable objects to other threads. But I think I  
> need to read TDPL concurrency chapter to clarify some things first of  
> all.

Implicit sharing of immutable is definitely an issue to consider.  If an  
object is immutable, then the mutable data is also implicitly sharable  
since the mutable data rides around with the object.  I don't have a good  
answer for this yet, but I don't think it's a deal-killer.  We may need to  
adjust the rules regarding sharing immutable data (i.e. you can't  
implicitly share immutable data, but you can cast it to shared to share  
it).

I thought implicit unshared felt completely wrong when it was first  
introduced, now I think it's completely correct.

-Steve