How to break const

Artur Skawina art.08.09 at gmail.com
Tue Jun 19 11:11:09 PDT 2012


On 06/19/12 19:30, Christophe Travert wrote:
> Artur Skawina , dans le message (digitalmars.D:170175), a écrit :
>> On 06/19/12 15:29, deadalnix wrote:
>>> Le 19/06/2012 14:30, Artur Skawina a écrit :
>>>>> Due to D concept of weak purity, this doesn't ensure the required what we need here.
>>>>
>>>> Actually, it does - if it can be proved that the delegate can't alter the object
>>>> via the context pointer (eg because whatever it points to is not mutable) then
>>>> even D's "pure" is enough. Because the delegate would need to be passed a mutable
>>>> ref to be able to alter the object, which then could hardly be constructed as
>>>> "breaking" constness.
>>>>
>>>> But such a limit (const/immutable context) would be a problem for the cases where
>>>> the delegate needs to alter some state (like export the result of some operation),
>>>> but does _not_ modify the object it's embedded in. Note that the current object may
>>>> very well be reachable (and mutable) from the delegate - but at some point you have
>>>> to trust the programmer. Sure, fixing this hole would be great, but /how/ - w/o
>>>> incurring unacceptable collateral damage?
>>>>
>>>
>>> This isn't a problem as long as the delegate isn't a member of the object. If it is, transitivity is broken, which is something you don't want.
>>>
>>> Relying on the trust on the programmer is a dumb idea. Human do mistake, way more than computers. The basic behavior MUST be a safe one.
>>>
>>> Transitivity has been introduced for good reason and language already provide a way to break it via cast. So it is unacceptable to rely on programmer on that point.
>>>
>>>>> It is possible to get the error when trying to call the delegate instead of preventing to make it const, as I said in the post you quote. It is probably a better solution.
>>>>
>>>> Any delegate?
>>>>
>>>
>>> No, any delegate that have type that isn't covariant with the expected delegate type.
>>
>>    struct S {
>>       int i; this(int i) { this.i = i; }
>>       T* p; 
>>       void f(int i) { this.i = i; /*p.i++;*/ }
>>    }
>>    struct T {
>>       int i; this(int i) { this.i = i; }
>>       void delegate(int i) f;
>>    }
>>
>>    void main() {
>>       auto t = new T(42);
>>       auto s = new S(17);
>>       s.p = t;
>>       t.f = &s.f;
>>       f(t);
>>    }
>>
>>    void f(const (T)* t) {
>>       t.f(t.i*2);
>>    }
>>
>> You're proposing to make the last 'f' function illegal, just because the
>> commented out part could happen. I'm saying that this is unlikely to happen
>> *by accident*, and of course would still be possible by casting away the
>> constness. 
>> But banning "unsafe" delegates would result in casts *when using "safe" ones*
>> - which is not a real improvement because this would make the "bad" casts much
>> harder to spot.
> 
> 
> The proper way to do this is not cast, it is to give the proper 
> constness for all types and methods :
> 
>    struct S {
>       int i; this(int i) { this.i = i; }
>       T* p; 
>       void f(int i) const { this.i = i; /*p.i++;*/ }
> // the commented part is illegal because S.f is const

Not just the commented part.

>    }
>    struct T {
>       int i; this(int i) { this.i = i; }
>       void delegate(int i) const f;
>   // T.f is const to be callable from .f
>    }
> 
>    void main() {
>       auto t = new T(42);
>       auto s = new S(17);
>       s.p = t;
>       t.f = &s.f; // legal when T.f is const because S.f is also const

Only a const T.f would be pointless.
Like I've already said twice in this thread - it *can* be done (the
function has to be "pure" too for it to work), but certain delegate
uses, which are OK now, would be forbidden.

I'm all for fixing this hole - it's just that the proposed "fix" would
have consequences, which can't simply be ignored.

Language design is not a game of whack-a-mole, where you ban random
features left and right, because you think you've noticed a problem,
without properly identifying it nor spending even a single second
figuring out the implications.

artur


More information about the Digitalmars-d mailing list