How to break const

Timon Gehr timon.gehr at gmx.ch
Mon Jun 18 09:04:01 PDT 2012


On 06/18/2012 05:12 PM, deadalnix wrote:
> Le 18/06/2012 16:51, Andrei Alexandrescu a écrit :
>> Mehrdad posted a code sample and you replied to it with what I could
>> only assume was an explanation of the code's behavior. I hope you'd
>> agree it was a reasonable assumption, whether or not it was correct.
>>
>> The problem at work here is that "this" is typed incorrectly during the
>> construction of a qualified object. It should go progressively from a
>> "raw" to a "cooked" state, and cannot be passed to any function while
>> raw.
>>
>>> I've however made other posts to explain why
>>> transitivity is broken when it comes to delegate.
>>
>> I looked at your posts through June and couldn't find such, so a couple
>> of links would be great. Of course, bug reports would be even better!
>>
>
> I'm not sure you are talking about the proposal or the transitivity
> issue here. I'll explain the proposal below, for the explaination of why
> the transitivity is broken, see :
> http://forum.dlang.org/thread/ywispsasaylqscyuayae@forum.dlang.org?page=2#post-jrn7sv:24jjj:241:40digitalmars.com
>
>
>
> 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?

> 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.

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.
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.




More information about the Digitalmars-d mailing list