How to break const

[Iain Buclaw]

On 19 June 2012 12:04, Timon Gehr <timon.gehr at gmx.ch> wrote:
> On 06/19/2012 12:49 PM, Iain Buclaw wrote:
>>
>> On 19 June 2012 10:47, Christophe Travert<travert at phare.normalesup.org>
>>  wrote:
>>>
>>> Iain Buclaw , dans le message (digitalmars.D:170145), a écrit :
>>>>
>>>> On 19 June 2012 09:18, Don Clugston<dac at nospam.com>  wrote:
>>>>>
>>>>> So would I. Can you think of one?
>>>>> It was the best name I could come up with, given that the 'pure' was
>>>>> the
>>>>> keyword.
>>>>> We want a word that means 'no hidden state'.
>>>>
>>>>
>>>> I thought that was what pure was for. :~)
>>>>
>>>> --
>>>> Iain Buclaw
>>>>
>>>> *(p<  e ? p++ : p) = (c&  0x0f) + '0';
>>>
>>>
>>>
>>> A delegate does have a frame pointer, and it's not that well hidden. If
>>> you want no such 'hidden state', you do not want a delegate, you want a
>>> function pointer. That means all delegates are weakly pure (until they
>>> have an immutable frame pointer qualifier).
>>>
>>> If you want that this 'hidden state' does not change, that is another
>>> story. pure for a delegate could mean that the frame pointer does not
>>> change, but then, pure methods wouldn't allow you to make pure
>>> delegates:
>>>
>>> struct S
>>> {
>>>  int i;
>>>  int foo() pure { return i; }
>>> }
>>>
>>> S s;
>>> int delegate() pure dg =&s.foo;
>>> // error if pure change meaning when applied to a delegate
>>>
>>
>> So we have a few combinations then:
>>
>> pure  - as in weakly pure, guarantees not to change global state, but
>> may alter it's own hidden state.
>>
>> pure nothrow - as in strongly pure, where is guaranteed not to have
>> any side effects, so is suitable for constant folding
>
>
> This would need to be qualified 'pure immutable nothrow', otherwise it
> might change it's own hidden state.
>
>
>> / the usual optimisations for a function typically marked as __pure__ in
>> C.
>>
>
> Some of them can even be applied if it is just 'pure immutable '. loop
> invariant code motion, for instance.
>
>
>> pure const - similar to strongly pure, as is guaranteed not to be able
>> to alter its own state (as it's const), but still may have side
>> effects / throw an exception.
>>
>
> Therefore, you think 'pure const' should be allowed to have side effects?
>

Throwing exceptions is a bit of a side effect...


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';