D on quora ...

Radu void at null.pt
Sun Oct 8 07:10:13 UTC 2017


On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
> 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)?
>

Yes, exceptions are one, but there are strings (arrays in 
general) for which ref counted needs to work, and it should work 
in @safe mode, so you need scope working to get it...

>> - 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 would make sense to have a documentation marker that allows 
one to quickly see that a module/function is usable in betterC 
mode. Algorithms and the like are first in line but it should be 
gradually extended to all parts of phobos... Right now this is a 
guess work.

> 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.
>

Yeah - they are entangled with a lot of parts from druntime and 
phobos, that's why I think they need a redesign that can deliver 
a core part that works with the C runtime (betterC), then extend 
on that to have the druntime one.

> 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