On Monday, 22 November 2021 at 12:33:46 UTC, Imperatorn wrote:

Yes, since the cycle detection is automatic there is no necessity to badge references as 'weak' in order to avoid cyclic references. So it is a compromise between reference counting and tracing GC. Nice really since automatic memory management should really be automatic.

On Monday, 22 November 2021 at 10:16:28 UTC, Araq wrote:

Thanks.

On Tuesday, 23 November 2021 at 19:22:11 UTC, Araq wrote:

The union issue can be fixed by using a selector-function, but it sounds like Nim and its memory management solution is higher level than D. It would probably be a mistake for D to follow there given the focus on importC etc.

On Tuesday, 23 November 2021 at 21:14:39 UTC, Ola Fosheim Grøstad wrote:

Not sure if I'm interpreting your answer correctly but there is no contradiction between managed pointers and raw pointers when it comes to interoperability. Nim can simply cast raw pointers from a managed pointers and pass them to FFI. Higher level of abstraction when in comes to memory management will not hurt FFI at all. The same cautions with FFIs as we have today must of course be taken.

On Tuesday, 23 November 2021 at 22:21:51 UTC, IGotD- wrote:

I don't know enough about Nim, but it would be a mistake to replace one memory management solution with another one, if it:

1. Still does not satisfy people who want something slightly higher level than C++, but low level enough to create competitive game engines.

2. Requires semantic changes that makes D more like Nim.

3. Increases the complexity of the compiler unnecessarily.

I would strongly favour simple schemes. So I'd rather see actor-local GC + ARC (without cycle detection).

Complex schemes tend to go haywire when people go hard in on low level hand-optimization. Programmers need to understand what goes on. As can be seen in the forums, many have a hard time understanding how the current GC works (despite it being quite simplistic). I can only imagine how many will fail to understand ORC…

Gentlemen, good afternoon.
Let me make a couple of comments.
I think D is an excellent language for rapid development and I am trying to
popularize it here in this vein.

This year I (suddenly) resumed my education
(second grade) and suddenly found myself as old experienced dude in a young student environment.

Tasks to be solved include programming. D ideally lie on almost all occasions.
It would seem that we are going "forward and upward". But ... There are several
stoppers at once.

First of all, the GUI and huge difficulties (for a student ---
not a professional programmer, but only a programming user) to draw the GUI
elements.
The data plotter window on D is an almost insoluble problem for a
student.

There are no full-fledged signals --- slots with the ability to exchange
data between threads (in the style of Qt) => whole familiar sections
immediately drop out.

In general, the absence of bindings to Qt and the
laboriousness of creating bindings to ordinary libraries is already a huge
stopper.

Async? Oops.

Finally, the situation, that most of the packages in the
dub registry are simply not compilable by the current versions of the compilers
(at least, without the shamanic dances with "depercated". It's inaccessible to the
average student).

IMHO, I would like to draw the first attention to this, then
the spread of the language could follow the same path as Python in the recent
past. From students to experienced peoples.

Automatically and successfully.

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

QtE5.

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

D has a native message system between threads. Qt signals is a special case as it also can be used in the same thread and then it is just a function call. Also there are syntax sugar for declaring Qt signals in C++.

I don't know any language that natively implements signals as Qt does.