D on quora ...

Laeeth Isharc laeethnospam at nospam.laeeth.com
Sat Oct 7 20:36:24 UTC 2017


On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:
> I think there is some merit criticizing D's GC.
>
> The major problem with it ATM is that there is no convenient 
> way to use all (most) of D's std lib without it.
>
> This also extends to third party libs - most of them are coded 
> with the GC in mind because of the above point.

I guess a non-GC solution for throw new Exception will help with 
quite a lot.  What to do about the rest (at least for Phobos)?

> - Allocators - right now they are in Phobos... This is not 
> great, they should be split in 2 parts: core an druntime. One 
> should be able to use a minimal set in betterC mode, and the 
> full version with druntime (all GC related parts).

Would it make sense to have a BetterC version define for Phobos?  
Or is this a terrible idea?  So you could still use some subset 
of Phobos from BetterC mode, and maybe this subset could be 
expanded over time?  And maybe people would write a complimentary 
set of functions to cover the missing most useful things in a way 
that doesn't depend on the runtime?

It makes sense what you say about allocators - it would be nice 
to be able to write BetterC code using those.  I used dscanner 
quickly to see what the imports are, and I wonder how much work 
it would be to do what you propose.

core.atomic
core.bitop
core.exception
core.internal.spinlock
core.memory
core.stdc.errno
core.stdc.stdlib
core.stdc.string
core.sys.posix.pthread
core.sys.posix.sys.mman
core.sys.windows.unknwn
core.sys.windows.windows
core.thread
std.algorithm.comparison
std.algorithm.iteration
std.algorithm.mutation
std.algorithm.searching
std.algorithm.sorting
std.array
std.c.stdlib
std.c.string
std.concurrency
std.conv
std.exceptionstd.file
std.format
std.internal.test.dummyrange
std.math
std.meta
std.random
std.range
std.range.primitives
std.stdio
std.traits
std.typecons





More information about the Digitalmars-d mailing list