On Thursday, 29 October 2020 at 21:34:06 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 29 October 2020 at 21:13:20 UTC, Paulo Pinto wrote:
>> Indeed, what I appreciate in the Java Panama/Valhala efforts, C# 7+ memory handling, Swift and Go, is the attitute to improve their low level programming capabilities without making concessions to the anti-GC folks.
>
> But Swift uses refcounting...

Which anyone with proper compiler teachings knows is a GC algorithm, unless their CS professor really screw up their CS books.

On Friday, 30 October 2020 at 07:19:13 UTC, Paulo Pinto wrote:
> On Thursday, 29 October 2020 at 21:34:06 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 29 October 2020 at 21:13:20 UTC, Paulo Pinto wrote:
>>> Indeed, what I appreciate in the Java Panama/Valhala efforts, C# 7+ memory handling, Swift and Go, is the attitute to improve their low level programming capabilities without making concessions to the anti-GC folks.
>>
>> But Swift uses refcounting...
>
> Which anyone with proper compiler teachings knows is a GC algorithm, unless their CS professor really screw up their CS books.

In the forums GC usually means a tracing GC. C++ has GC too, then.

On Friday, 30 October 2020 at 07:46:58 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 30 October 2020 at 07:19:13 UTC, Paulo Pinto wrote:
>> On Thursday, 29 October 2020 at 21:34:06 UTC, Ola Fosheim Grøstad wrote:
>>> On Thursday, 29 October 2020 at 21:13:20 UTC, Paulo Pinto wrote:
>>>> Indeed, what I appreciate in the Java Panama/Valhala efforts, C# 7+ memory handling, Swift and Go, is the attitute to improve their low level programming capabilities without making concessions to the anti-GC folks.
>>>
>>> But Swift uses refcounting...
>>
>> Which anyone with proper compiler teachings knows is a GC algorithm, unless their CS professor really screw up their CS books.
>
> In the forums GC usually means a tracing GC. C++ has GC too, then.

I like to fix urban myths, and RC not being a GC algorithm is such a myth.

The other one is about its actual performance against modern tracing GC implementations.

Regarding C++, it does have one as part of C++11 GC API, C++/CLI, C++/CX and Unreal C++.

On Thu, Oct 29, 2020 at 11:00 PM Paul Backus via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> I have a DIP I think you'll like:
>
>
> https://github.com/dlang/DIPs/blob/02594a09d9daf1d393ebce2cfc2f0c4f90d4bcf8/DIPs/1NNN-PJB.md


Nice DIP, but why not added as a https://dlang.org/phobos/core_attribute.html this would mean no breaking change

On Friday, 30 October 2020 at 08:39:17 UTC, Paulo Pinto wrote:
> Regarding C++, it does have one as part of C++11 GC API, C++/CLI, C++/CX and Unreal C++.

There are some definitions in the standard library for a tracing GC in C++. What I meant was that atomic_shared_ptr might qualify as automatic reference counting since you don't have to do explicit acquire/release. Even though most people don't think that C++ has automatic reference counting. Swift has some optimization of it though.

On 10/30/20 5:32 AM, Ola Fosheim Grøstad wrote:
> On Friday, 30 October 2020 at 08:39:17 UTC, Paulo Pinto wrote:
>> Regarding C++, it does have one as part of C++11 GC API, C++/CLI, C++/CX and Unreal C++.
> 
> There are some definitions in the standard library for a tracing GC in C++. What I meant was that atomic_shared_ptr might qualify as automatic reference counting since you don't have to do explicit acquire/release. Even though most people don't think that C++ has automatic reference counting. Swift has some optimization of it though.
> 

Yes, swift builds on top of Objective-C ARC. Pairs of RC increment and decrements are elided because the compiler knows what it means. And Swift no longer has to deal with auto release pools as the compiler is smarter about return values.

I think D was looking at one point to be able to do this, but via a specialized library hook.

The difference between RC and a tracing GC is that cycles can prevent garbage from being detected in RC, whereas tracing can find those.

Even in swift, you have a notion of weak references that get auto-nullified when the target gets destroyed, and not properly setting up an ownership relationship will result in items not being collected. But certainly it's much easier than the Objective-C requirements.

-Steve

On Friday, 30 October 2020 at 14:24:43 UTC, Steven Schveighoffer wrote:
> I think D was looking at one point to be able to do this, but via a specialized library hook.
>
> The difference between RC and a tracing GC is that cycles can prevent garbage from being detected in RC, whereas tracing can find those.
>
> Even in swift, you have a notion of weak references that get auto-nullified when the target gets destroyed, and not properly setting up an ownership relationship will result in items not being collected. But certainly it's much easier than the Objective-C requirements.

*nods* Yes, you need weak references. I did like your idea of having reference counting and using the current GC-collection infrastructure for detecting cycles and dangling pointers. I think dynamic sanitizers can be very powerful.

Class objects are already quite heavy as each interface adds another pointer to each object, so I don't think adding two counters would make a catastrophic difference.

I once made a prototype refcounting scheme in D with borrowing that tracked the number of borrows at runtime. You could even add tracking of __FILE__ and __LINE__ and get good debug tracking during testing.

So there are interesting possibilities without "throwing out everything". E.g. retaining key properties of the tracing GC for development and drop down to ARC at release.

On Friday, 30 October 2020 at 09:15:32 UTC, Daniel Kozak wrote:
> On Thu, Oct 29, 2020 at 11:00 PM Paul Backus via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>>
>> I have a DIP I think you'll like:
>>
>>
>> https://github.com/dlang/DIPs/blob/02594a09d9daf1d393ebce2cfc2f0c4f90d4bcf8/DIPs/1NNN-PJB.md
>
>
> Nice DIP, but why not added as a https://dlang.org/phobos/core_attribute.html this would mean no breaking change

No reason at all--I just didn't think of it at the time. Thanks for the tip!

On 10/29/2020 5:00 AM, rikki cattermole wrote:
> Runtime less D and pay-as-you-go.
> 
> These are being worked on over time. They are basically the same thing, use as much of druntime as you want (i.e. some, or none).
> 
> -betterC fills its role, and doesn't need rebranding.

Future efforts with the library will be for so-called "header only" libraries, where one just imports the library module, and there's no need to link the library too.

On 10/29/2020 5:48 AM, Abdulhaq wrote:
> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.

D popularized CTFE, and other languages followed suit, including Jai.