23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
> On 23 September 2014 16:19, deadalnix via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
>     Digitalmars-d wrote:
>
>         I still think most of those users would accept RC instead of GC.
>         Why not
>         support RC in the language, and make all of this library noise
>         redundant?
>         Library RC can't really optimise well, RC requires language
>         support to
>         elide ref fiddling.
>
>
>     I think a library solution + intrinsic for increment/decrement (so
>     they can be better optimized) would be the best option.
>
>
> Right, that's pretty much how I imagined it too. Like ranges, where
> foreach makes implicit calls to contractual methods, there would also be
> a contract for refcounted objects, and the compiler will emit implicit
> calls to inc/dec if they exist?

In my imagination it would be along the lines of
@ARC
struct MyCountedStuff{ void opInc(); void opDec(); }

> That should eliminate 'RefCounted', you would only need to provide
> opInc()/opDec() and rc fiddling calls would be generated automatically?

Non-intrusive ref-counts are useful too. And not everybody is thrilled by writing inc/dec code again and again.

> Then we can preserve the type of things, rather than obscuring them in
> layers of wrapper templates...

This would be intrusive ref-counting which may be more efficient.


-- 
Dmitry Olshansky

On 23 September 2014 17:17, Dmitry Olshansky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
>>
>> On 23 September 2014 16:19, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>
>>     On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
>>     Digitalmars-d wrote:
>>
>>         I still think most of those users would accept RC instead of GC.
>>         Why not
>>         support RC in the language, and make all of this library noise
>>         redundant?
>>         Library RC can't really optimise well, RC requires language
>>         support to
>>         elide ref fiddling.
>>
>>
>>     I think a library solution + intrinsic for increment/decrement (so
>>     they can be better optimized) would be the best option.
>>
>>
>> Right, that's pretty much how I imagined it too. Like ranges, where foreach makes implicit calls to contractual methods, there would also be a contract for refcounted objects, and the compiler will emit implicit calls to inc/dec if they exist?
>
>
> In my imagination it would be along the lines of
> @ARC
> struct MyCountedStuff{ void opInc(); void opDec(); }

Problem with this is you can't make a refcounted int[] without mangling the type, and you also can't allocate a ref counted 3rd-party type.

>> That should eliminate 'RefCounted', you would only need to provide
>> opInc()/opDec() and rc fiddling calls would be generated automatically?
>
>
> Non-intrusive ref-counts are useful too. And not everybody is thrilled by writing inc/dec code again and again.

It's important to be able to override opInc/opDec for user types, but I think a default scheme for foreign or builtin types is very important.

>> Then we can preserve the type of things, rather than obscuring them in layers of wrapper templates...
>
>
> This would be intrusive ref-counting which may be more efficient.

Perhaps I'm not clear what you mean by intrusive/non-intrusive?

On Monday, 22 September 2014 at 23:11:42 UTC, Andrei Alexandrescu wrote:
>
> I agree. It does have legs however. We should learn a few things from it, such as green threads, dependency management, networking libraries. Also Go shows that good quality tooling makes a lot of a difference. And of course the main lesson is that templates are good to have :o).
>
Go also shows the viability of a fixup tool for minor automated code changes as the language develops.

-Wyatt

On Monday, 22 September 2014 at 09:45:23 UTC, Ola Fosheim Grostad wrote:
>
> Locking fibers to threads will cost you more than using threadsafe features. One 300ms request can then starve waiting fibers even if you have 7 free threads. That's bad for latency, because then all fibers on that thread will get 300+ms in latency.

I don't understand what you're getting at.  Nothing in D locks fibers to threads.  In fact, the MultiScheduler I'm going to write if the original Scheduler pull request is ever accepted will not work this way.  Granted, that means that use of thread-local storage will be utterly broken instead of mostly broken, but I think it's a fair exchange for not having a single long-running fiber block other fibers.

On 9/22/14, 11:44 PM, Manu via Digitalmars-d wrote:
> On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d
> The trouble with library types like RefCounted!, is that they appear to
> be conceptually backwards to me.
> RefCounted!T suggests that T is a parameter to RefCounted, ie,
> RefCounted is the significant object, not 'T', which is what I actually
> want. T is just some parameter... I want a ref-counted T, not a T
> RefCounted, if that makes sense.
> When we have T* or T[], we don't lose the 'T'-ness of the object, we're
> just appending a certain type of pointer, and I really think that RC
> should be applied the same way.

That's at most a syntactic issue but not a conceptual one. We have things like Array!T and nobody blinks an eye.

> All these library solutions make T into something else, and that has a
> tendency to complicate generic code in my experience. In most cases,
> templates are used to capture some type of thing, but in these
> RefCounted style cases, it's backwards, it effectively obscures the
> type.

As it should. You wouldn't want RefCounted!int to be the same as int*.

> We end out with inevitable code like is(T == RefCounted!U, U) to
> get U from T, which is the thing we typically want to know about, and
> every instance of a template like this must be special-cased; they can't
> be rolled into PointerTarget!T, or other patterns like Unqual!T can't
> affect these cases (not applicable here, but the reliable pattern is
> what I refer to).

It turns out a class type is a good candidate for embedding ref countedness in its type; in contrast, RefCounted can be slapped on any value type. That's how we plan to make it to work.

> I guess I'm saying, RC should be a type of pointer, not a type of
> thing...

It /is/ a pointer. The longer name for it would be RefCountedPointer. It has pointer semantics. If you're looking for pointer syntax as well, that would be a bummer.


Andrei

On 9/22/14, 11:47 PM, Manu via Digitalmars-d wrote:
> On 23 September 2014 16:19, deadalnix via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
>     Digitalmars-d wrote:
>
>         I still think most of those users would accept RC instead of GC.
>         Why not
>         support RC in the language, and make all of this library noise
>         redundant?
>         Library RC can't really optimise well, RC requires language
>         support to
>         elide ref fiddling.
>
>
>     I think a library solution + intrinsic for increment/decrement (so
>     they can be better optimized) would be the best option.
>
>
> Right, that's pretty much how I imagined it too. Like ranges, where
> foreach makes implicit calls to contractual methods, there would also be
> a contract for refcounted objects, and the compiler will emit implicit
> calls to inc/dec if they exist?
> That should eliminate 'RefCounted', you would only need to provide
> opInc()/opDec() and rc fiddling calls would be generated automatically?
> Then we can preserve the type of things, rather than obscuring them in
> layers of wrapper templates...

That won't work. Sorry, it has too many holes to enumerate! -- Andrei

On 9/23/14, 12:17 AM, Dmitry Olshansky wrote:
> In my imagination it would be along the lines of
> @ARC
> struct MyCountedStuff{ void opInc(); void opDec(); }

So that would be a pointer type or a value type? Is there copy on write somewhere? -- Andrei

On 9/23/14, 5:51 AM, Wyatt wrote:
> On Monday, 22 September 2014 at 23:11:42 UTC, Andrei Alexandrescu wrote:
>>
>> I agree. It does have legs however. We should learn a few things from
>> it, such as green threads, dependency management, networking
>> libraries. Also Go shows that good quality tooling makes a lot of a
>> difference. And of course the main lesson is that templates are good
>> to have :o).
>>
> Go also shows the viability of a fixup tool for minor automated code
> changes as the language develops.
>
> -Wyatt

Yah, we definitely should have one of our mythical lieutenants on that. -- Andrei

On Tuesday, 23 September 2014 at 15:43:41 UTC, Andrei Alexandrescu wrote:
>
> Yah, we definitely should have one of our mythical lieutenants on that. -- Andrei

I distinctly remember someone offering to write one and being shot down (by Walter?).

-Wyatt

On 9/23/14, 9:02 AM, Wyatt wrote:
> On Tuesday, 23 September 2014 at 15:43:41 UTC, Andrei Alexandrescu wrote:
>>
>> Yah, we definitely should have one of our mythical lieutenants on
>> that. -- Andrei
>
> I distinctly remember someone offering to write one and being shot down
> (by Walter?).

The offer was in the context of a feature that was being rejected. -- Andrei