www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Memory safe and coroutines are the focus of D.

reply zoujiaqing <zoujiaqing gmail.com> writes:
Memory safe:
Now there are two programming languages to solve memory safe. One 
is that rust-language limits memory safe when writing. The other 
is that swift-language uses ARC to manage memory to ensure memory 
safe. I think D should do more like swift.

Coroutines:
Golang successfully achieved high concurrency by using 
coroutines. C++ also introduces the concept of coroutine. The 
latest Java version also introduces the virtual threads. As a 
concurrent language, shouldn't D support this feature?
Oct 16 2022
parent reply IGotD- <nise nise.com> writes:
On Sunday, 16 October 2022 at 17:59:41 UTC, zoujiaqing wrote:

 Memory safe:
 Now there are two programming languages to solve memory safe. 
 One is that rust-language limits memory safe when writing. The 
 other is that swift-language uses ARC to manage memory to 
 ensure memory safe. I think D should do more like swift.


Not going to happen because Walter do not want to have managed 
pointers in the language. So we just have raw pointers in D just 
like we have now. How do we add arbitrary managed memory (ARC or 
whatever you want) with only raw pointers? I don't know and I 
don't say it's impossible but that could be a fun D conference 
talk.

As for the Swift comparison, it has value types which are 
allocated on the stack and then it has classes which are 
allocated on the heap. This in Swift does not exist (you can do 
this if you resort to some unsafe types).

```d
int *intPtr = new int;
```

Swift also does allocation on the heap of structs which are value 
types under certain conditions so there is more going on under 
the hood there. Programmer will never see this unless they debug 
the code. This can also make havoc if you start to copy these 
heap allocated value types which can cause more heap allocations 
without you knowing it.

If D would follow the same separation as Swift, then ARC for only 
classes would be possible. Also that would be a reason not to use 
D because I like to heap allocate whatever I want.
Oct 16 2022
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 16 October 2022 at 20:22:47 UTC, IGotD- wrote:

 Not going to happen because Walter do not want to have managed 
 pointers in the language. So we just have raw pointers in D 
 just like we have now. How do we add arbitrary managed memory 
 (ARC or whatever you want) with only raw pointers? I don't know 
 and I don't say it's impossible but that could be a fun D 
 conference talk.


Can you give elaborate or give references on the topic of using 
managed pointers that do ARC? Are some bits of the address used 
to store the reference count. What about other languages like 


I find lots of articles on managed pointers in Swift like 
https://www.vadimbulavin.com/swift-pointers-overview-unsafe-buffer-raw-a
d-managed-pointers/ but no information on how they are actually encoded on the
bit-level.
Oct 16 2022
next sibling parent IGotD- <nise nise.com> writes:
On Sunday, 16 October 2022 at 22:07:59 UTC, Per Nordlöw wrote:

 Can you give elaborate or give references on the topic of using 
 managed pointers that do ARC? Are some bits of the address used 
 to store the reference count. What about other languages like 


 I find lots of articles on managed pointers in Swift like 
 https://www.vadimbulavin.com/swift-pointers-overview-unsafe-buffer-raw-a
d-managed-pointers/ but no information on how they are actually encoded on the
bit-level.


Not that easy to find information about the memory layout of the 
Swift data structures. What I've understood in this page

https://academy.realm.io/posts/goto-mike-ash-exploring-swift-memory-layout/

is that the reference count (which is called retain count in 
Swift world) is stored in the beginning of the class structure 
together with the members, two counters, one strong count and one 
weak count. It's really the most simple way to store it as only 
classes have reference counting in Swift.

Swift has a bunch of unsafe raw pointers but one that is 
interesting the unmanaged wrapper. With that one if you wrap your 
class in a unmanaged wrapper then it basically becomes a manually 
reference counted class. This can be useful if you have a code 
section you know the class will be alive and you can do away with 
all the increase/decrease of the reference count (which is also 
atomic).

Reference counting really adds to the instrumentation of the 
code, like the unmanaged wrapper, you have to deal with 
strong/weak references. Swift is talking about adding movable 
types, borrow/take modifiers to reduce the counting.

https://forums.swift.org/t/borrow-and-take-parameter-ownership-modifiers/59581

It's not all glamour with ARC and it has its downsides as well.
Oct 16 2022
prev sibling parent reply rassoc <rassoc posteo.de> writes:
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/
Oct 16 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
Oct 16 2022
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Oct 17 2022
next sibling parent reply Araq <rumpf_a web.de> writes:
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 

'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.
Oct 17 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 17 October 2022 at 17:50:29 UTC, Araq wrote:

 [snip]
 The distinction between managed and unmanaged pointers can also 

 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.


The ability to create managed and unmanaged pointers is separate 
from built-in language support for them. D has the ability to 
create types like shared_ptr, but it doesn't have the equivalent 
functionality that Nim has in terms of two built-in pointer types.

On 1, even if it is clear to the user what pointer type to use, 
it's not always clear when to use which pointer type from the 
perspective of the library writer. The library writer might want 
the library to be indifferent to what memory management scheme is 
used. They might be in the position of writing two versions of 
the function (or a templated version of the function) that 
supports each of the pointer types.

On 2, I would agree that automatic memory management does tend to 
work better, but that doesn't mean that some people don't want to 
use manual MM.
Oct 19 2022
parent IGotD- <nise nise.com> writes:
On Wednesday, 19 October 2022 at 18:50:37 UTC, jmh530 wrote:

 On 1, even if it is clear to the user what pointer type to use, 
 it's not always clear when to use which pointer type from the 
 perspective of the library writer. The library writer might 
 want the library to be indifferent to what memory management 
 scheme is used. They might be in the position of writing two 
 versions of the function (or a templated version of the 
 function) that supports each of the pointer types.


It usually very clear what pointer type to use and you can see it 
everywhere in other languages. It is that they use the native 
managed pointer for libraries intended to be used in the 

only the native reference and value types.

If you create FFI functions intended to be used by many 
languages, then you have no choice other than using raw pointers 
which is only common denominator there is.
Oct 19 2022
prev sibling parent reply zoujiaqing <zoujiaqing gmail.com> writes:
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.
Oct 18 2022
parent Sergey <kornburn yandex.ru> writes:
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.
Oct 19 2022