On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
> The problem at hand here is escape analysis. The compiler must be able to ensure that a reference doesn't escape the RC mechanism in an uncontrolled manner. I'd like to add such mechanism to the language rather than bake in reference counting, as it can be used to solve other problem we are facing today (@nogc exception for instance).

I would also have a definite interest in this for the direction I'm considering taking with an alternative std.random design.

Technically, I suspect my particular use-case is covered by DIP25, but a more comprehensive solution to escape analysis would definitely make it more secure.

On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>  Why care about this?
>
>  Even Rust doesn't try to solve this problem...because it isn't really a problem in practice.
>
>  In c++/rust code you use value/unique types 99.9% of the time, and reference counting is only for shared/aliased objects.

I agree with your sentiment that local reference counting is seldom needed, but shared reference counting is needed for shared cached objects. So shared (atomic) reference counting have a common and important use case.

Not sure if shared ref counting is addressed here at all though.

On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>  Why care about this?
>
>  Even Rust doesn't try to solve this problem...because it isn't really a problem in practice.
>
>  In c++/rust code you use value/unique types 99.9% of the time, and reference counting is only for shared/aliased objects.
>
>
>  Reference counting == rare and unimportant

Really? I've seen tons of C++ code that's written using smart pointers with objects living on the heap which then get passed around all over the place.

Sure, a lot of stuff in D should be structs on the stack, but there are plenty of cases where you need stuff on the heap, in which case, you either have to let the GC take care of it (which means no deterministic destruction), have something specific own it and destroy it when it's no longer needed, or reference count it so that it gets destroyed immediately after it's no longer needed. For cases where you don't care about deterministic destruction, using the GC is fine, but for those cases where deterministic destruction is required (e.g. because the object currently has ownership of an OS resource), the GC doesn't cut it, and ref-counting is very much what's needed.

If/when we introduce ref-counting into the language, I fully expect that there will be a lot of D programs written which specifically use it in order to avoid the GC. And while in many cases, that's going to be an unnecessary, in some cases, it'll be a lifesaver.

As it stands, we can add ref-counting via libraries just fine, but it requires giving up on @safe, which we could probably live with, but it would make @safe a lot less valuable in the long run. So, a solution that enables @safe ref-counting in D would certainly be desirable, and we definitely need a language improvement of some kind if we want to be able to ref-count something like exceptions (be it by building ref-counting into the language like Andrei is proposing or by adding other features which enable us to build it in the library like deadalnix is proposing).

- Jonathan M Davis

On Tuesday, 27 October 2015 at 20:41:49 UTC, Jonathan M Davis wrote:
> On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>>  Why care about this?
>>
>>  Even Rust doesn't try to solve this problem...because it isn't really a problem in practice.
>>
>>  In c++/rust code you use value/unique types 99.9% of the time, and reference counting is only for shared/aliased objects.
>>
>>
>>  Reference counting == rare and unimportant
>
> Really? I've seen tons of C++ code that's written using smart pointers with objects living on the heap which then get passed around all over the place.

if they're using shared_ptr all over the place, they're doing it wrong.
shared_ptr is supposed to be a last resort

On Tuesday, 27 October 2015 at 20:45:34 UTC, rsw0x wrote:
> if they're using shared_ptr all over the place, they're doing it wrong.
> shared_ptr is supposed to be a last resort

According to Herb Sutter, it is a zero cost abstraction, not like these pesky GC that makes your program slow.

On Tuesday, 27 October 2015 at 20:41:49 UTC, Jonathan M Davis wrote:
> On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>>  [...]
>
> Really? I've seen tons of C++ code that's written using smart pointers with objects living on the heap which then get passed around all over the place.
>
> [...]

I can't believe you actually took the time to dignify this with a response...but on the other hand, I previously had no opinion about @safety...But if its a reason to include language level ref counting, then I guess I'm all for it :)

   Bit

On 10/27/2015 04:19 PM, PuglyWUgly wrote:
>   Reference counting == rare and unimportant

That doesn't seem to be the case at all. -- Andrei

On 10/27/2015 04:45 PM, rsw0x wrote:
> On Tuesday, 27 October 2015 at 20:41:49 UTC, Jonathan M Davis wrote:
>> On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>>>  Why care about this?
>>>
>>>  Even Rust doesn't try to solve this problem...because it isn't
>>> really a problem in practice.
>>>
>>>  In c++/rust code you use value/unique types 99.9% of the time, and
>>> reference counting is only for shared/aliased objects.
>>>
>>>
>>>  Reference counting == rare and unimportant
>>
>> Really? I've seen tons of C++ code that's written using smart pointers
>> with objects living on the heap which then get passed around all over
>> the place.
>
> if they're using shared_ptr all over the place, they're doing it wrong.
> shared_ptr is supposed to be a last resort

This is awesomely Kafkian. So we have no problem after all - just like Go with generics :o). -- Andrei

On Tuesday, 27 October 2015 at 21:20:58 UTC, Andrei Alexandrescu wrote:
> On 10/27/2015 04:45 PM, rsw0x wrote:
>> On Tuesday, 27 October 2015 at 20:41:49 UTC, Jonathan M Davis wrote:
>>> On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
>>>>  Why care about this?
>>>>
>>>>  Even Rust doesn't try to solve this problem...because it isn't
>>>> really a problem in practice.
>>>>
>>>>  In c++/rust code you use value/unique types 99.9% of the time, and
>>>> reference counting is only for shared/aliased objects.
>>>>
>>>>
>>>>  Reference counting == rare and unimportant
>>>
>>> Really? I've seen tons of C++ code that's written using smart pointers
>>> with objects living on the heap which then get passed around all over
>>> the place.
>>
>> if they're using shared_ptr all over the place, they're doing it wrong.
>> shared_ptr is supposed to be a last resort
>
> This is awesomely Kafkian. So we have no problem after all - just like Go with generics :o). -- Andrei

It has been a great success for Rust, I rarely ever see RC used anywhere in Rust code thanks to borrowing. The new C++ core guidelines are also heavily based on this cf. *_view types in GSL.

The problem D has is that RC isn't even implemented at library level let alone in a state where it's unsafe. IIRC Phobos RC doesn't even allow classes.

On 10/27/2015 05:26 PM, rsw0x wrote:
> It has been a great success for Rust, I rarely ever see RC used anywhere
> in Rust code thanks to borrowing. The new C++ core guidelines are also
> heavily based on this cf. *_view types in GSL.

You can safely ignore the C++ part, the views are unsafe. I'd appreciate if you backed up your claim on Rust. -- Andrei