Wednesday, 25 February 2015 at 20:01:51 UTC, Andrei Alexandrescu wrote:
> On 2/25/15 11:04 AM, Ivan Timokhin wrote:
>> OK, thank you. I wasn't asking about DIP25 in particular (I think I
>> understand what it's about), but about your (and Walter's) plans on
>> the topic in general.
>
> The medium-term plan is two-pronged: (a) immediately apply DIP25 to http://wiki.dlang.org/?title=DIP74, which will propose @safe reference counted class objects; (b) examine scoped borrowing (DIP69 and friends) opportunities post DIP25.
>
> Walter and I are working on DIP74 right now.
>
>
> Andrei

As someone who directly complained about this, this is awesome. Can't wait to read DIP74.

On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
> On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
>> Note, you need to GC.addRange all the elements if the type has
>> references, or else you cannot have GC pointers in the array. For
>> example, an array of class references could potentially result in those
>> references being collected before the array is gone.
>>
>> Ironically, if those elements are references, but are reference counted
>> references, then you wouldn't need to addRange. An interesting problem...
>
> Could you please add a detailed issue about this? Thanks. -- Andrei
>

I'm not sure what you mean by 'this'. As far as I can tell, it isn't a bug in GC but a bug in your dpaste code.

-Steve

On 2/26/15 8:44 AM, Steven Schveighoffer wrote:
> On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
>> On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
>>> Note, you need to GC.addRange all the elements if the type has
>>> references, or else you cannot have GC pointers in the array. For
>>> example, an array of class references could potentially result in those
>>> references being collected before the array is gone.
>>>
>>> Ironically, if those elements are references, but are reference counted
>>> references, then you wouldn't need to addRange. An interesting
>>> problem...
>>
>> Could you please add a detailed issue about this? Thanks. -- Andrei
>>
>
> I'm not sure what you mean by 'this'. As far as I can tell, it isn't a
> bug in GC but a bug in your dpaste code.
>
> -Steve

I'm referring to the "interesting problem" of adding addRange for some but not all types. -- Andrei

On 2/26/15 11:56 AM, Andrei Alexandrescu wrote:
> On 2/26/15 8:44 AM, Steven Schveighoffer wrote:
>> On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
>>> On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
>>>> Note, you need to GC.addRange all the elements if the type has
>>>> references, or else you cannot have GC pointers in the array. For
>>>> example, an array of class references could potentially result in those
>>>> references being collected before the array is gone.
>>>>
>>>> Ironically, if those elements are references, but are reference counted
>>>> references, then you wouldn't need to addRange. An interesting
>>>> problem...
>>>
>>> Could you please add a detailed issue about this? Thanks. -- Andrei
>>>
>>
>> I'm not sure what you mean by 'this'. As far as I can tell, it isn't a
>> bug in GC but a bug in your dpaste code.
>
> I'm referring to the "interesting problem" of adding addRange for some
> but not all types. -- Andrei

OK, but I don't know where to add that :( RC isn't supported by D today. You mean add it to a DIP? Add it to the docs?

I don't think it's mechanically checkable, BTW. If you have an array of pointers, each pointer may point at a GC-allocated block, or a C malloc-allocated block. I suppose at the time of setting an element, you can addRange if necessary. But the cost for that I think far outweighs the benefit of using RC.

-Steve