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