How to break const

[deadalnix]

Le 18/06/2012 18:04, Timon Gehr a écrit :
>> To explain my proposal, I have to make several thing clear first. You
>> have here 2 things to qualify : the delegate itself, and the hidden
>> parameter. As type qualifier are transitive in D, qualify the delegate
>> also transitively qualify the hidden parameter.
>>
>> The proposal was to use postfix qualifier notation to qualify the hidden
>> parameter, and qualifier between return type and delegate keyword to
>> qualify the delegate itself.
>
> Why would the second part of the proposal be necessary?
>

What do you qualify as the second part ?

>> My original proposal stated that the type
>> qualifier before the return type qualify the return type, but this is
>> another topic.
>>
>> To make is clearer, some examples :
>>
>> void delegate() const; // A mutable delegate that use const frame
>> pointer (all variable accessed throw the frame pointer are made const).
>> void const delegate(); // A const delegate that use a const frame
>> pointer (transitivity).
>> void const delegate() immutable; // A const delegate that use an
>> immutable frame pointer (delegate can only access immutable data from
>> the frame pointer).
>> void immutable delegate() const; // Error, immutable data cannot refers
>> to const data.
>>
>> Note that the implicit cast goes the other way around than usual. void
>> delegate() const can be safely casted to void delegate(), but not the
>> other way around, as you are allowed to not mutate mutable data, but not
>> the other way around.
>
> Comments:
>
> 1.
>
> struct S{
> int x;
> void foo()pure{x++;} // ok
> }
>
> void main(){
> int x;
> void foo()pure{x++;} // currently an error
> }
>
> The second part should be allowed. It is qualifying foo as 'immutable'
> which should fail.
>

Yes.

> 2.
>
> int y;
> struct S{
> int x;
> void foo()immutable{y++;} // ok
> }
>
> void main(){
> void foo()immutable{y++;} // should be allowed
> }
>
> The problem is the unfortunate annotation overhead.

And yes. This is another topic, but I think the way to go is inference.

> It would be better to have 'nostatic' as the keyword for the
> current 'pure' and 'pure' as a shortcut for 'immutable nostatic'.
>
> This would also silence the 'pure is a misnomer' crowd.
>

I don't really have an opinion on that subject. I understand the keywork 
choice can be confusing, but the overall design is really nice.