On Thursday, 27 February 2014 at 16:10:34 UTC, Adam D. Ruppe wrote:
> struct RefCountingStruct {
>     private struct Impl {
>       // implementation here
>
>       int refcount;
>     }
>     Impl* payload;
>     alias payload this;


Isn't it exactly what Phobos RefCounted does?

On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:
> On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
>> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>>
>> Priceless for message passing concurrency.
>
> Tbh it only looks worse and worse to me :(
>
> Another example of code necessary to overcome language limitations.

Or, alternatively:

A language flexible enough to facilitate library solutions for problems that would normally require explicit language support.

On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:
> On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:
>> On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
>>> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>>>
>>> Priceless for message passing concurrency.
>>
>> Tbh it only looks worse and worse to me :(
>>
>> Another example of code necessary to overcome language limitations.
>
> Or, alternatively:
>
> A language flexible enough to facilitate library solutions for problems that would normally require explicit language support.

I dig flexibility, I really do, and I appreciate D's features that enable that, but in case of such basic thing as a resource management, I just want things to work without surprises by default.

On Thursday, 27 February 2014 at 17:31:57 UTC, Dicebot wrote:
> Isn't it exactly what Phobos RefCounted does?

Yes, though knowing how the implementation works is good for stuff like interfacing with C where you might need different acquire/free/add count/release functions than phobos uses.

http://dlang.org/phobos/std_typecons.html#RefCounted

It always uses malloc and free, which isn't always (actually, in my cases, is rarely ever) what you want.

It is (obviously) possible to write a generic one that takes aliases (or delegates if you want all refcounted things to have the same parent type regardless of allocation strategy) for these functions, I've done that somewhere on the ng or my http server before too, but phobos doesn't do that either.

The phobos one also doesn't let you wrap classes which is sometimes useful.

On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner wrote:
> I dig flexibility, I really do, and I appreciate D's features that enable that, but in case of such basic thing as a resource management, I just want things to work without surprises by default.

Resource management (including memory management) is on of most complicated areas in programming. I can call it anything but basic.

On Thu, 27 Feb 2014 18:29:55 -0000, Szymon Gatner <noemail@gmail.com> wrote:

> On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:
>> On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:
>>> On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
>>>> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>>>>
>>>> Priceless for message passing concurrency.
>>>
>>> Tbh it only looks worse and worse to me :(
>>>
>>> Another example of code necessary to overcome language limitations.
>>
>> Or, alternatively:
>>
>> A language flexible enough to facilitate library solutions for problems that would normally require explicit language support.
>
> I dig flexibility, I really do, and I appreciate D's features that enable that, but in case of such basic thing as a resource management, I just want things to work without surprises by default.

Amen.  (Not used religiously)

I have been around D for a long time, and I have noticed a growing trend of solving problems with "clever" but complicated library solutions when in *some* cases a simpler built-in solution was possible.  I realise Walter's time is precious and I realise that adding complexity to the language itself is something to be generally avoided, but I think sometimes we make the wrong choice.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 28 February 2014 at 10:45:53 UTC, Regan Heath wrote:
> On Thu, 27 Feb 2014 18:29:55 -0000, Szymon Gatner <noemail@gmail.com> wrote:
>
>> On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:
>>> On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:
>>>> On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
>>>>> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>>>>>
>>>>> Priceless for message passing concurrency.
>>>>
>>>> Tbh it only looks worse and worse to me :(
>>>>
>>>> Another example of code necessary to overcome language limitations.
>>>
>>> Or, alternatively:
>>>
>>> A language flexible enough to facilitate library solutions for problems that would normally require explicit language support.
>>
>> I dig flexibility, I really do, and I appreciate D's features that enable that, but in case of such basic thing as a resource management, I just want things to work without surprises by default.
>
> Amen.  (Not used religiously)
>
> I have been around D for a long time, and I have noticed a growing trend of solving problems with "clever" but complicated library solutions when in *some* cases a simpler built-in solution was possible.  I realise Walter's time is precious and I realise that adding complexity to the language itself is something to be generally avoided, but I think sometimes we make the wrong choice.
>
> R

Yeah scope -> scoped is IMO such a wrong choice. :)

On Friday, 28 February 2014 at 10:44:22 UTC, Dicebot wrote:
> On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner wrote:
>> I dig flexibility, I really do, and I appreciate D's features that enable that, but in case of such basic thing as a resource management, I just want things to work without surprises by default.
>
> Resource management (including memory management) is on of most complicated areas in programming. I can call it anything but basic.

I didn't mean "basic" in the sense of "easy" but in the sense of something that has to dealt with all the time / is common requirement.

"Programs == Algorithms + Data structures" great man once said. D is pretty damn good at algorithms part, better than C++ thanks to ranges (zero cost composability codegen issues aside) but data strucutres... I wish I felt the same way about them.

Is it really so much to ask for? That child's finalizers are called before parent finalizer (assuming no circular refs, then again there are no weak class refst in D right)? Parent holds references to them for crying out loud... Why is that not the default and obvious behaviour? Is that a limitation imposed by GC somehow? My understanding is that GC has to scan from root to leaves so it knows the structure exactly anyway, why not just generate finalizer call list when traversing?

On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner wrote:
> I didn't mean "basic" in the sense of "easy" but in the sense of something that has to dealt with all the time / is common requirement.

Yes, it needs to be dealt with all the time but in a different ways. Problem is with getting sensible defaults. D makes a reasonable assumption that most applications don't actually care about tight bullet-proof resource management and defaults to GC. I may not like it but it fits criteria "built-in resource management" and pretty much shows that it is not as basic as one may think.

> "Programs == Algorithms + Data structures" great man once said. D is pretty damn good at algorithms part, better than C++ thanks to ranges (zero cost composability codegen issues aside) but data strucutres... I wish I felt the same way about them.

Most problems I have with D data structures come from qualifiers, not from resource management. I really don't understand why this looks that much of a problem. That said, my background very influenced by plain C and that results in different habits and expectations.

> Is that a limitation imposed by GC somehow? My understanding is that GC has to scan from root to leaves so it knows the structure exactly anyway, why not just generate finalizer call list when traversing?

Can't tell because of my very limited knowledge about GC internals. In practice I don't care because I never ever want to interfere with GC resource mangement -  stuff that I want to micro-managed is allocated from custom pools and thus is not a subject to unexpected destructor calls.

On 2/28/2014 8:43 PM, Dicebot wrote:

>
> Most problems I have with D data structures come from qualifiers, not
> from resource management. I really don't understand why this looks that
> much of a problem. That said, my background very influenced by plain C
> and that results in different habits and expectations.

I have a strong C background as well and have never had any complaints about resource management in D. Every complaint I've seen has come from people trying to do C++-like RAII. And, though I don't understand it either, it does seem to be a big issue for them.