Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
> On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum <jakobovrum@gmail.com>
> wrote:
>
>> On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
>>> Does anyone else find this behavior too strict?
>>
>> Yes. Sounds like yet another case of forcing bitwise const on
>> something that should only be logically const.
>>
>> Please stop forcing bitwise constancy on everything. Not everything
>> needs to work with immutable, it should be opt-in (which in this case
>> could mean explicitly marking the invariant as const) for any type.
>
> I was about to argue that non-const invariants could not be called when
> calling const or immutable member functions, but then it hit me that
> those shouldn't be able to influence the state checked by the invariant
> anyway.
>

That is a very good point. Should invariant run on const/immutable method calls ?

On 05-08-2012 11:47, Simen Kjaeraas wrote:
> On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum <jakobovrum@gmail.com>
> wrote:
>
>> On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
>>> Does anyone else find this behavior too strict?
>>
>> Yes. Sounds like yet another case of forcing bitwise const on
>> something that should only be logically const.
>>
>> Please stop forcing bitwise constancy on everything. Not everything
>> needs to work with immutable, it should be opt-in (which in this case
>> could mean explicitly marking the invariant as const) for any type.
>
> I was about to argue that non-const invariants could not be called when
> calling const or immutable member functions, but then it hit me that
> those shouldn't be able to influence the state checked by the invariant
> anyway.
>

Sure they can. If the invariant can influence something outside of the object, then it can potentially influence the object's members. For example, a global variable could hold a non-const reference to something that the object also has a reference to.

Aliasing is a bitch. ;)

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 06-08-2012 19:57, deadalnix wrote:
> Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
>> On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum <jakobovrum@gmail.com>
>> wrote:
>>
>>> On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
>>>> Does anyone else find this behavior too strict?
>>>
>>> Yes. Sounds like yet another case of forcing bitwise const on
>>> something that should only be logically const.
>>>
>>> Please stop forcing bitwise constancy on everything. Not everything
>>> needs to work with immutable, it should be opt-in (which in this case
>>> could mean explicitly marking the invariant as const) for any type.
>>
>> I was about to argue that non-const invariants could not be called when
>> calling const or immutable member functions, but then it hit me that
>> those shouldn't be able to influence the state checked by the invariant
>> anyway.
>>
>
> That is a very good point. Should invariant run on const/immutable
> method calls ?

They should.

In the real world, things are not as nice as const and immutable would have you believe. Things can be modified indirectly by the invariant (through a global variable for example), or even by another thread. We need invariants to run as often as possible to catch problems like these instead of pretending they don't exist.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org