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

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 16 08:38:01 PDT 2014


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



More information about the Digitalmars-d mailing list