On Sunday, 18 February 2018 at 21:12:11 UTC, Martin Nowak wrote:
>
> [snip]

Interesting reading. Thanks for the update.

On Sunday, 18 February 2018 at 21:58:57 UTC, jmh530 wrote:
> On Sunday, 18 February 2018 at 21:12:11 UTC, Martin Nowak wrote:
>>
>> [snip]
>
> Interesting reading. Thanks for the update.

Indeed, very interesting read and exactly the information I was looking for! Thanks a lot Martin, I'm excited to see this progress. It's good to know it's still being worked on and progress is being made.

On Sunday, 18 February 2018 at 22:28:48 UTC, Peter Campbell wrote:
> Indeed, very interesting read and exactly the information I was looking for! Thanks a lot Martin, I'm excited to see this progress. It's good to know it's still being worked on and progress is being made.

Yes, it's just crazy how much work and expertise is involved with a programming language ecosystem, so things always go much slower than intended.

In case someone wants to help, I currently have to divert a lot of time into https://github.com/dlang/dub. Package managers are suprisingly complex pieces of software. We have some basic architecture https://github.com/dlang/dub/blob/master/ARCHITECTURE.md and would benefit a lot from a few more contributors getting familiar with the implementation.

Thank you for this status report, much appreciated, and exactly the kind of thing I hope for.  Don’t be discouraged by the time it has taken, it will be worth it.  Good work!

On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell wrote:
>
> I've read about BetterC and I'm interested in the minimal runtime feature, that seems like it'll be really cool. But these methods requiring not using certain D features which rely on the GC. My understanding from the vision documents and what Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct? If so is work still being done to make this happen and is there an easy way to follow the progress?
>

Any more progress regard this? Dynamic arrays and associative arrays are very useful even in a betterC environment. Wouldn't it be better to rewrite the dynamic arrays to use an internal storage struct using atomic reference counting similar to C++ strings (at least in some previous implementations). This way arrays are only dependent malloc/free. Using the reference counting, slicing would be supported just as before if I'm not mistaken.

I also don't think this should be special variant of druntime. Reference counted dynamic arrays could go into the full D language as well. This would probably even reduce the memory consumption compared to the current GC implementation.

On Sunday, 6 October 2019 at 12:50:04 UTC, IGotD- wrote:
> Dynamic arrays and associative arrays are very useful even in a betterC environment. Wouldn't it be better to rewrite the dynamic arrays to use an internal storage struct using atomic reference counting similar to C++ strings

I think that'd be a mistake. D's slices are versatile and lightweight right now, they can be used with gc or malloc or anything else and this change would jeopardize that.

It is easy to make a library array type that works like you described, and it can even yield built-in slices when you want that.

If anything I'd just let you disable built in dynamic array append/concat so it calls out when you need to put in a wrapper...