There's been a lot of talk lately regarding improving resource management for D, and I'd like to figure the next logical step to take. It seems clear that we have reached a collective impasse on a few fundamentals, and that more just talk about it all is at the point of diminishing returns.

One action item that is hopefully useful to people of all viewpoints is to double down on library support, and see how far we can get and what insights we collect from the experience.

For that I'm proposing we start real work toward a state-of-the-art std.refcounted module. It would include adapters for class, array, and pointer types, and should inform language improvements for qualifiers (i.e. the tail-const problem), copy elision, literals, operators, and such.

Who wants to champion this effort?


Thanks,

Andrei

On 12/05/14 21:00, Andrei Alexandrescu wrote:
> There's been a lot of talk lately regarding improving resource
> management for D, and I'd like to figure the next logical step to take.
> It seems clear that we have reached a collective impasse on a few
> fundamentals, and that more just talk about it all is at the point of
> diminishing returns.
>
> One action item that is hopefully useful to people of all viewpoints is
> to double down on library support, and see how far we can get and what
> insights we collect from the experience.
>
> For that I'm proposing we start real work toward a state-of-the-art
> std.refcounted module. It would include adapters for class, array, and
> pointer types, and should inform language improvements for qualifiers
> (i.e. the tail-const problem), copy elision, literals, operators, and such.

Perhaps, as has been already stared, sprinkle Phobos with output ranges and/or allocators.

-- 
/Jacob Carlborg

On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote:
> For that I'm proposing we start real work toward a state-of-the-art std.refcounted module. It would include adapters for class, array, and pointer types, and should inform language improvements for qualifiers (i.e. the tail-const problem), copy elision, literals, operators, and such.

We don't have language tools to do it. Main problem with implementing reference counted pointers as structs is that you are forced to abandon polymorphism:

class A {}
class B : A {}

void foo(RefCounted!A) {}

void main()
{
    RefCounted!B b = new B();
    foo(b); // no way to make it work
}

This severely limits applicability of such library solution, especially when it comes to something like exceptions.

On actual topic of next step - I agree with Jacob, removing all
internal allocations from Phobos is most beneficial short-term
goal.

On 5/13/14, 6:41 AM, Dicebot wrote:
> On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote:
>> For that I'm proposing we start real work toward a state-of-the-art
>> std.refcounted module. It would include adapters for class, array, and
>> pointer types, and should inform language improvements for qualifiers
>> (i.e. the tail-const problem), copy elision, literals, operators, and
>> such.
>
> We don't have language tools to do it. Main problem with implementing
> reference counted pointers as structs is that you are forced to abandon
> polymorphism:
>
> class A {}
> class B : A {}
>
> void foo(RefCounted!A) {}
>
> void main()
> {
>      RefCounted!B b = new B();
>      foo(b); // no way to make it work
> }
>
> This severely limits applicability of such library solution, especially
> when it comes to something like exceptions.

"alias this" should be of help here. Could you please try it? Thanks! -- Andrei

On 5/13/14, 6:43 AM, Dicebot wrote:
> On actual topic of next step - I agree with Jacob, removing all
> internal allocations from Phobos is most beneficial short-term
> goal.

That's a given. This task and improving RC don't compete (except, of course, for bearing on the same people). I ask again, who wants to champion std.refcounted? Rainer? Manu? Michel? Are you there? -- Andrei

On 05/13/2014 05:11 PM, Andrei Alexandrescu wrote:
> On 5/13/14, 6:41 AM, Dicebot wrote:
>> On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote:
>>> For that I'm proposing we start real work toward a state-of-the-art
>>> std.refcounted module. It would include adapters for class, array, and
>>> pointer types, and should inform language improvements for qualifiers
>>> (i.e. the tail-const problem), copy elision, literals, operators, and
>>> such.
>>
>> We don't have language tools to do it. Main problem with implementing
>> reference counted pointers as structs is that you are forced to abandon
>> polymorphism:
>>
>> class A {}
>> class B : A {}
>>
>> void foo(RefCounted!A) {}
>>
>> void main()
>> {
>>      RefCounted!B b = new B();
>>      foo(b); // no way to make it work
>> }
>>
>> This severely limits applicability of such library solution, especially
>> when it comes to something like exceptions.
>
> "alias this" should be of help here. Could you please try it? Thanks! --
> Andrei
>

class A{
    RefCounted!A r(){ ... }
}

class B : A {
    override RefCounted!B r(){ ... } // ...
}

RefCounted!B[] b;
RefCounted!(const(A))[] a=b; // ...

etc.

On Tuesday, 13 May 2014 at 15:11:48 UTC, Andrei Alexandrescu wrote:
> On 5/13/14, 6:41 AM, Dicebot wrote:
>> On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote:
>>> For that I'm proposing we start real work toward a state-of-the-art
>>> std.refcounted module. It would include adapters for class, array, and
>>> pointer types, and should inform language improvements for qualifiers
>>> (i.e. the tail-const problem), copy elision, literals, operators, and
>>> such.
>>
>> We don't have language tools to do it. Main problem with implementing
>> reference counted pointers as structs is that you are forced to abandon
>> polymorphism:
>>
>> class A {}
>> class B : A {}
>>
>> void foo(RefCounted!A) {}
>>
>> void main()
>> {
>>     RefCounted!B b = new B();
>>     foo(b); // no way to make it work
>> }
>>
>> This severely limits applicability of such library solution, especially
>> when it comes to something like exceptions.
>
> "alias this" should be of help here. Could you please try it? Thanks! -- Andrei

We don't have multiple alias this to cover all parent classes. Also you can't throw struct as an Exception. Also Timon's example.

On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote:
> There's been a lot of talk lately regarding improving resource management for D, and I'd like to figure the next logical step to take. It seems clear that we have reached a collective impasse on a few fundamentals, and that more just talk about it all is at the point of diminishing returns.
>
> One action item that is hopefully useful to people of all viewpoints is to double down on library support, and see how far we can get and what insights we collect from the experience.
>
> For that I'm proposing we start real work toward a state-of-the-art std.refcounted module. It would include adapters for class, array, and pointer types, and should inform language improvements for qualifiers (i.e. the tail-const problem), copy elision, literals, operators, and such.
>
> Who wants to champion this effort?
>
>
> Thanks,
>
> Andrei

Also please std.typecons.refcounted, let's stop that flat
hierarchy madness.

On 5/13/2014 6:43 AM, Dicebot wrote:
> On actual topic of next step - I agree with Jacob, removing all
> internal allocations from Phobos is most beneficial short-term
> goal.

I'm working on it. Could use some help!