On Wed, Dec 06, 2023 at 01:42:02AM +0000, monkyyy via Digitalmars-d wrote:
> On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:
> > worseD
> > half the std
> 
> I feel like the big thing is that slices depend on gc, and if you dont have slices how exactly can you use all the algorithms which, oh yeah, like to try to make ranges of dchar if you use any char then which wont be fitting in whatever you allocated
[...]

This is wrong, slices do not depend on gc.  *Appending* to slices does (because you have to allocate memory to store the result), but you can pass slices around @nogc code no problem. Taking slices of an existing array (which need not be GC-allocated) is also @nogc. In fact, most of std.algorithm, std.range, can be used with @nogc, the primary blocker there is Exceptions which are GC-allocated.

(Incidentally this is why there was talk about @nogc Exceptions a while back, the idea being that once we get rid of GC dependency for Exception, then basically all of std.algorithm and std.range would be usable in @nogc.)


T

-- 
Let X be the set not defined by this sentence...

On Wednesday, 6 December 2023 at 02:32:20 UTC, H. S. Teoh wrote:
[...]
> (Incidentally this is why there was talk about @nogc Exceptions a while back, the idea being that once we get rid of GC dependency for Exception, then basically all of std.algorithm and std.range would be usable in @nogc.)

The exception itself doesn't need to be GC allocated and this already kinda works with some limitations (not good enough for Phobos, but maybe usable for the other @nogc use cases). This reminds me of https://forum.dlang.org/post/kjkjagzrengbynkoffgy@forum.dlang.org

On Wednesday, 6 December 2023 at 02:32:20 UTC, H. S. Teoh wrote:
>
> This is wrong, slices do not depend on gc.  *Appending* to slices does (because you have to allocate memory to store the result), but you can pass slices around @nogc code no problem. Taking slices of an existing array (which need not be GC-allocated) is also @nogc. In fact, most of std.algorithm, std.range, can be used with @nogc, the primary blocker there is Exceptions which are GC-allocated.
>
> (Incidentally this is why there was talk about @nogc Exceptions a while back, the idea being that once we get rid of GC dependency for Exception, then basically all of std.algorithm and std.range would be usable in @nogc.)
>
>
> T

True but D has this duality between slices and dynamic arrays and they are sometimes hard to distinguish and there can be allocations underneath when you least expect it.

For me the problem with D isn't really GC but rather the type of GC. For embedded systems memory allocations are fine but the huge amount of instrumentation in order to get the GC to work is unacceptable (stopping threads, reading registers, reading TLS etc). The default GC is also too old and not up to the task for a modern desktop/laptop/server computer systems. D was created when dual core processors was the coolest thing for desktops. Now normal computers have up to 32 cores and multithreading is more common. Stopping 32+ threads takes time as is a really ugly approach. Therefore D needs to evolve in order to accommodate for a more variety of GC types and not only the stop the world type. Now it only supports one GC type which is a design error built into the language/library.

Honestly, I couldn't care less about @nogc even if I'm doing embedded systems. The embedded systems that are so memory constrained that you have avoid do memory allocations, then better C or C alone is the obvious choice for those systems, not using the D library at all.