• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (8/8) Jan 01 2021 Is there a rough plan for where D is heading with memory
• IGotD- (11/19) Jan 01 2021 We absolutely need a roadmap and a vision where D needs to go
• Paul Backus (5/14) Jan 01 2021 Personally I would like to see some clarity on the status of, and
• Max Haughton (12/33) Jan 01 2021 I mentioned having a working group on memory safety previously.
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/6) Jan 01 2021 That would be great.
• RSY (4/39) Jan 01 2021 i'm not sure yet another @ will solve anything

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

Is there a rough plan for where D is heading with memory 
management in 2021?

Just roughly?

I also wonder if it would be possible to use refcounting (or ARC) 
for everything except class objects. Then add write barriers for 
pointers to class objects only and leave those garbage collected 
with a lower latency incremental mark/sweep collector. That 
should work out mostly ok for performance?

IGotD- <nise nise.com> writes:

On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?

We absolutely need a roadmap and a vision where D needs to go 
when it comes to memory management. Many of us expected this to 
clear up with Walter's presentation at Dconf 2020 but it was more 
basic explaining the concepts with the borrow/checker and was not 
something that revealed any information about any direction of 
the memory management in D.

This is a subject with a lot of opinions but the D project has to 
do through with this despite it demands a lot of work and 
discussions.

Paul Backus <snarwin gmail.com> writes:

On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 We absolutely need a roadmap and a vision where D needs to go 
 when it comes to memory management. Many of us expected this to 
 clear up with Walter's presentation at Dconf 2020 but it was 
 more basic explaining the concepts with the borrow/checker and 
 was not something that revealed any information about any 
 direction of the memory management in D.

 This is a subject with a lot of opinions but the D project has 
 to do through with this despite it demands a lot of work and 
 discussions.

Personally I would like to see some clarity on the status of, and 
future plans for, std.experimental.allocator. What needs to 
happen for it to "graduate" into std proper? Who (if anyone) is 
working on making that happen?

Max Haughton <maxhaton gmail.com> writes:

On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
 wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?

 We absolutely need a roadmap and a vision where D needs to go 
 when it comes to memory management. Many of us expected this to 
 clear up with Walter's presentation at Dconf 2020 but it was 
 more basic explaining the concepts with the borrow/checker and 
 was not something that revealed any information about any 
 direction of the memory management in D.

 This is a subject with a lot of opinions but the D project has 
 to do through with this despite it demands a lot of work and 
 discussions.

I mentioned having a working group on memory safety previously. 
If I all goes to plan I am supposed to be Mike's glamorous 
assistant soon-ish(?) (thank you symmetry), and I would be very 
interesting in running something along those lines.

Memory safety is a bit of Pandora's box, though, because it means 
getting move semantics right not only directly but also in what 
to do with the moved-from object (for example). We have the 
option to not be C++ on this matter, and we should probably take 
it.

What  live does is where we should be aiming for - RAII alone 
isn't good enough any more.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Saturday, 2 January 2021 at 00:03:11 UTC, Max Haughton wrote:
 I mentioned having a working group on memory safety previously.

That would be great.
Maybe use this forum:

https://forum.dlang.org/group/study

Then people could follow the various ideas?

RSY <rsy_881 gmail.com> writes:

On Saturday, 2 January 2021 at 00:03:11 UTC, Max Haughton wrote:
 On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
 wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?

 We absolutely need a roadmap and a vision where D needs to go 
 when it comes to memory management. Many of us expected this 
 to clear up with Walter's presentation at Dconf 2020 but it 
 was more basic explaining the concepts with the borrow/checker 
 and was not something that revealed any information about any 
 direction of the memory management in D.

 This is a subject with a lot of opinions but the D project has 
 to do through with this despite it demands a lot of work and 
 discussions.

 I mentioned having a working group on memory safety previously. 
 If I all goes to plan I am supposed to be Mike's glamorous 
 assistant soon-ish(?) (thank you symmetry), and I would be very 
 interesting in running something along those lines.

 Memory safety is a bit of Pandora's box, though, because it 
 means getting move semantics right not only directly but also 
 in what to do with the moved-from object (for example). We have 
 the option to not be C++ on this matter, and we should probably 
 take it.

 What  live does is where we should be aiming for - RAII alone 
 isn't good enough any more.

i'm not sure yet another   will solve anything

I personally avoid them because they clutter the code, just like 
comments, people tend to abuse them..