> 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.

 Yes there is lots of old C++ code that does this, largely because unique_ptr wasn't implementable until C++11 added R value refs and move semantics.

> 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.

 on the heap == unique_ptr
 on the heap + multiple owners = shared_ptr

 If you work in a codebase that properly uses unique types, like Rust does by default, you soon notice how rare multiple owners actually is.

 Well perhaps D prefers the Swift route, with everyone ref counted & some compiler help.

Nothing wrong with that I guess, I haven't been paying attention to what D is planning exactly.

On Tuesday, 27 October 2015 at 21:50:15 UTC, Andrei Alexandrescu wrote:
> 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

rustc's source has about a 5:1 Box:Rc usage ratio after a quick grepping of the codebase(ignoring tests ofcourse.) This isn't counting all the cases where borrowed pointers were used instead of RC(which has about a 33.4:1 Borrowed:Rc usage after a quick grepping)

On Tuesday, 27 October 2015 at 21:50:15 UTC, Andrei Alexandrescu wrote:
> 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

That is ultimately irrelevant. Be it unique_ptr or shared_ptr, the same problem arise: this must not escape.

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


 I did a rough check of the Rust compiler source(from a copy I downloaded a couple months ago).

I think the compiler is supposedly filled with old code, not sure if it is the best example of Rust.

 I filtered out the rc/arc.rs files, and doc/test folders

 Some of these hits were comments/commented out, but I'm too lazy to bother removing them

Anyway:

Searching 7524 files for "Rc::new(" (case sensitive)

122 matches across 49 files

Searching 7524 files for "Arc::new(" (case sensitive)

60 matches across 28 files

On Tuesday, 27 October 2015 at 21:50:15 UTC, Andrei Alexandrescu wrote:
> 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

Well, even if the claims for Rust and C++ were both 100% true, the fact remains that we need to do something about ref-counting in D, because the alternative is the GC, which is not necessarily acceptable. We already put lots of stuff on the stack and encourage avoiding allocations (so, in that respect, we're already doing what it's being suggested C++ and Rust do) - but some code simply needs to allocate to do what it does, and while the GC actually works fantastically for that in many cases, there are cases where it doesn't - particularly when you need deterministic destruction. So, even if if ref-counting in D ends up being very rare, and even if we don't care about @safety, we still need a way to support ref-counting for classes (preferably a standard way). And since we do care about @safety, it behooves us to at least investigate what the possible solutions are for having @safe ref-counting in D (and preferably implement one of them) rather than simply accepting that ref-counting can't be @safe.

Personally, I think that one of the most important aspects of this is finding a way to make it possible to reasonably use exceptions in @nogc code. Right now, @nogc is almost synonymous with nothrow, which is not at all good IMHO. I do not want us to start doing stuff like returning error codes just so that our code can be @nogc.

- Jonathan M Davis

On 10/27/2015 11:10 AM, deadalnix wrote:
> I've made the claim that we should implement reference counting as a library
> many time, so I think I should explicit my position. Indeed, RC require some
> level a compiler support to be safe. That being said, the support does not need
> to be specific to RC. On fact, my position is that the language should provide
> some basic mechanism on top of which safe RC can be implemented, as a library.


It's not just safety. If the compiler knows that reference counting is going on, it can potentially elide a lot of the overhead. If it is faced with an arbitrary library solution, it only has a worm's eye view of it, and cannot do higher level optimizations.

On 10/27/2015 9:03 AM, Andrei Alexandrescu wrote:
> On 10/27/15 11:59 AM, Jonathan M Davis wrote:
>> What's the lifetime mailing list?
>
> To be created. -- Andrei

And you'll be in it for life, so be sure you want to join :-)

On Tuesday, 27 October 2015 at 11:41:52 UTC, Andrei Alexandrescu wrote:
> The crux of the matter is modular typechecking. Consider the following example:
>
> // module widget.d
> @safe class Widget {
>   void fun() {
>     g_widget = this;
>   }
> }
> static Widget g_widget;
> // end of module widget.d
>
> Now, once the typechecker OKs module widget.d, the summary that all other typechecking "sees" is:
>
> @safe class Widget {
>   void fun();
> }

Isn't it a shame that that kind of information gets tossed aside? Seems to be very valuable and the loss of it the cause of several issues.

On Wednesday, 28 October 2015 at 02:08:18 UTC, Sebastiaan Koppe wrote:
> On Tuesday, 27 October 2015 at 11:41:52 UTC, Andrei Alexandrescu wrote:
>> The crux of the matter is modular typechecking. Consider the following example:
>>
>> // module widget.d
>> @safe class Widget {
>>   void fun() {
>>     g_widget = this;
>>   }
>> }
>> static Widget g_widget;
>> // end of module widget.d
>>
>> Now, once the typechecker OKs module widget.d, the summary that all other typechecking "sees" is:
>>
>> @safe class Widget {
>>   void fun();
>> }
>
> Isn't it a shame that that kind of information gets tossed aside? Seems to be very valuable and the loss of it the cause of several issues.

Perhaps, but that assignment is perfectly @safe. What isn't @safe is when you then free the Widget later because a ref-count hit 0. And that code already has to be @system or @trusted given what it's doing. So, really, the problem is that some @safe operations can lead to problems when @system code does stuff that assumes that those operations did not occur. So, unfortunately, whether that code can be @trusted depends on what some @safe code did rather than @system code like you'd normally expect. But the compiler simply doesn't understand enough about why something is @system to be able to figure out where @safe code could foul it up even if it has all of the source code to look at.

- Jonathan M Davis