How to break const

[Timon Gehr]

On 06/20/2012 08:02 PM, Artur Skawina wrote:
> On 06/20/12 15:58, Christophe Travert wrote:
>> Artur Skawina , dans le message (digitalmars.D:170305), a écrit :
>>> On 06/20/12 09:31, Christophe Travert wrote:
>>>> Artur Skawina , dans le message (digitalmars.D:170191), a écrit :
>>>>>> 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
>>>>
>>>> I missed that. Then I disagree with your use of delegates. The solution
>>>> here is to make the free f function to take a non const T*, since the
>>>> function tries to modify variables from that T instance (via a
>>>> delegate).
>>>
>>> The issue is the delegate definition - what exactly is a delegate?
>>> My first message in this thread started with this sentence:
>>> "It's fine, if you view a delegate as opaque". Because if you do, then
>>> accesses via a delegates context pointer are no different from using
>>> an external reference. That message also contained a program to show
>>> how trivial bypassing const is, at least for impure functions. So
>>> banning "unsafe" delegates wouldn't really change the situation.
>>
>> Having opaque delegate and no holes in the langage is a possibility, but
>> not without changing the langage spec.
>>
>> With opaque delegates, you can't have a pure delegate, only pure
>> function pointers, because pure means you do not access external data,
>> and accessing data pointed by a the opaque frame pointer of the delegate
>> would be accessing external data.
>>
>> You may then redefine pure for delegate as delegates having only
>> immutable external data (const is not enough).
>>
>> I'm definitely not in favor of that solution.
>
> I agree with all of the above, maybe except the last sentence.
> The choice is between a) status quo, where the delegates are treated
> similarly to impure free functions, and b) handled "correctly".
> With scheme "a" I would expect to encounter genuine bugs extremely rarely,
> if ever; while if "b" would be enforced, the bugs directly or indirectly
> caused by working around the limitations would be plenty...
> Having a "cleaner" design, but one that results in more bugs is not really
> an improvement. Maybe there is a middle ground.
>

The type system must be sound. Some type system constraints can be
loosened, however.

> Anyway, that problem is not likely to get fixed quickly. In the mean time,
> there are serious compiler bugs related to the thread subject, which likely
> could. For example:
>
>     import std.stdio;
>
>     struct S {
>        int i; this(int i) { this.i = i; }
>        auto mutable() pure { return&i; }
>        void iAintAfraidOfNoConst() const pure { *(&mutable)()=-1813; }
>     }
>
>     void main() {
>        auto s = new immutable(S)(42);
>        writeln(*s);
>        s.iAintAfraidOfNoConst();
>        writeln(*s);
>     }
>
> The '&const(this).mutable' operation is clearly bogus and should not be
> allowed. But the compiler happily creates a delegate from a method and
> an incompatible instance reference, which in this case results in 'const'
> being dropped.
>
> (I have no DMD

http://dlang.org/download.html

> - can't test if the problem is still there, hence can't
> file a bug report)
>
> artur

It is still there.