Escaping the Tyranny of the GC: std.rcstring, first blood

Rainer Schuetze via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 21 02:53:01 PDT 2014



On 16.09.2014 17:38, Andrei Alexandrescu wrote:
> On 9/15/14, 4:49 PM, Rainer Schuetze wrote:
>>
>>
>> On 15.09.2014 10:24, Andrei Alexandrescu wrote:
>>>>
>>>> Hmm, seems fine when I try it. It feels like a bug in the type system,
>>>> though: when you make a copy of const(RCXString) to some RCXString, it
>>>> removes the const from the referenced RCBuffer struct mbuf!?
>>>
>>> The conversion relies on pure constructors. As I noted in the opening
>>> post, I also think there's something too lax in there. If you have a
>>> reduced example that shows a type system breakage without cast, please
>>> submit.
>>
>> Here's an example:
>>
>> module module2;
>>
>> struct S
>> {
>>      union
>>      {
>>          immutable(char)* iptr;
>>          char* ptr;
>>      }
>> }
>>
>> void main()
>> {
>>      auto s = immutable(S)("hi".ptr);
>>      S t = s;
>>      t.ptr[0] = 'A';
>> }
>>
>> It seems the union is hiding the fact that there are mutable references.
>> Only the first field is verified when copying the struct. Is this by
>> design? (typeof(s.ptr) is "immutable(char*)")
>
> Not sure whether that's a bug or feature :o). In fact I'm not even
> kidding. The "it's a bug" view is obvious. The "it's a feature" view
> goes by the reasoning: if you're using a union, it means you plan to do
> gnarly things with the type system anyway, so the compiler may as well
> tread carefully around you.
>
> Through a rather interesting coincidence, I was talking to Walter during
> the weekend about the idiom:
>
> union
> {
>      immutable T data;
>      T mdata;
> }
>
> which I found useful for things like incrementing the reference counter
> for non-mutable data. I was discussing how it would be cool if the
> compiler recognized the construct and did something interesting about
> it. It seems it already does.
>
>
> Andrei
>

There is already bug report for this: 
https://issues.dlang.org/show_bug.cgi?id=12885

It also references the issue why this has been changed pretty recently: 
https://issues.dlang.org/show_bug.cgi?id=11257

I'm on the fence whether this is convenient or makes it too easy to 
break const "guarantees". It seems strange that you can modify a 
const-reference only after you make a copy of the "pointer". ATM I'd 
prefer seeing an explicite cast for that.


More information about the Digitalmars-d mailing list