On 10/17/22 00:07, Per Nordlöw via Digitalmars-d wrote:
> Can you give elaborate or give references on the topic of using managed pointers that do ARC?

Aside from Swift, you might also want to check out Nim. They have tracing (ref) and untracing (ptr) pointers and recently made the jump to ARC/ORC by utilizing destructors and move semantic optimization which allows them to avoid certain RC downsides. But I'm clueless about what impact that had in the Nim world, I did not follow it closely.

[1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
[2] https://nim-lang.org/docs/destructors.html
[3] https://zevv.nl/nim-memory/

On Sunday, 16 October 2022 at 23:28:15 UTC, rassoc wrote:
> On 10/17/22 00:07, Per Nordlöw via Digitalmars-d wrote:
>> Can you give elaborate or give references on the topic of using managed pointers that do ARC?
>
> Aside from Swift, you might also want to check out Nim. They have tracing (ref) and untracing (ptr) pointers and recently made the jump to ARC/ORC by utilizing destructors and move semantic optimization which allows them to avoid certain RC downsides. But I'm clueless about what impact that had in the Nim world, I did not follow it closely.
>
> [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
> [2] https://nim-lang.org/docs/destructors.html
> [3] https://zevv.nl/nim-memory/

Or go all the back back to the early 80's with Mesa/Cedar used for a Xerox PARC graphical workstation, and component based OS.

This session from Eric Bier at Computer History Museum, demos the OS, https://www.youtube.com/watch?v=z_dt7NG38V4

Mesa/Cedar used reference counting with a cycle collector.

"On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-Checked, Concurrent Language" Xerox report,

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf

On Sunday, 16 October 2022 at 23:28:15 UTC, rassoc wrote:
> On 10/17/22 00:07, Per Nordlöw via Digitalmars-d wrote:
>> Can you give elaborate or give references on the topic of using managed pointers that do ARC?
>
> Aside from Swift, you might also want to check out Nim. They have tracing (ref) and untracing (ptr) pointers and recently made the jump to ARC/ORC by utilizing destructors and move semantic optimization which allows them to avoid certain RC downsides. But I'm clueless about what impact that had in the Nim world, I did not follow it closely.
>
> [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html
> [2] https://nim-lang.org/docs/destructors.html
> [3] https://zevv.nl/nim-memory/

Walter's argument against this has been that it forces the user to write multiple copies of the function to support both pointer types. Even if you have a templated version to handle it, you would still have two copies.

You would need some kind of type erasure, similar to inout (not that inout pulls its weight), and I'm sure there would be a lot of complications associated with it.

On Monday, 17 October 2022 at 14:51:09 UTC, jmh530 wrote:
>
> Walter's argument against this has been that it forces the user to write multiple copies of the function to support both pointer types. Even if you have a templated version to handle it, you would still have two copies.
>
> You would need some kind of type erasure, similar to inout (not that inout pulls its weight), and I'm sure there would be a lot of complications associated with it.

The distinction between managed and unmanaged pointers can also be found in: C#, C++ (shared_ptr), Rust (Arc), Swift, Go (Go uses 'uint' for untraced pointers IIRC)... In practice it doesn't lead to multiple copies of the same code for two reasons:
1. It's clear when to use which pointer type.
2. Unmanaged pointers are used much more rarely because automatic memory management simply works much better than manual MM; it's simply much more cost effective.

On Monday, 17 October 2022 at 14:51:09 UTC, jmh530 wrote:
>
> Walter's argument against this has been that it forces the user to write multiple copies of the function to support both pointer types. Even if you have a templated version to handle it, you would still have two copies.
>
> You would need some kind of type erasure, similar to inout (not that inout pulls its weight), and I'm sure there would be a lot of complications associated with it.

GC is not a good system level programming language.

Microsoft and Linux started supporting rust because of memory security.

Apple iOS apps developed with swift will run more smoothly because of memory security.

On Wednesday, 19 October 2022 at 06:34:54 UTC, zoujiaqing wrote:
> On Monday, 17 October 2022 at 14:51:09 UTC, jmh530 wrote:
> Apple iOS apps developed with swift will run more smoothly because of memory security.

Did you heard about Val? It is inspired on both Swift and C++ https://www.val-lang.dev/
But it is just in the begining of the road and lack of vision how Concurrency should be done properly.