How to break const

deadalnix deadalnix at gmail.com
Wed Jun 20 07:05:44 PDT 2012


Le 20/06/2012 15:58, Christophe Travert a écrit :
> 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.
>

Non, opaque delegate, whatever it means, means breaking immutability and 
shared transitivity. Which is a 100% NO.

Introducing implicit sharing would be a major step backward in D design.


More information about the Digitalmars-d mailing list