memory management and the standard library

[Jacob Carlborg]

On 2019-03-14 22:32, JN wrote:

> To be frank, even though I'd love the idea of D3, I don't think it's 
> just a matter of Phobos. Phobos is a victim of the underlying ideology 
> of D, which is both it's blessing and a curse. That ideology is the idea 
> that all paradigms are equal and every usecase should be supported. In 
> languages like Java/C#, if someone asks how to do manual memory 
> management, the answer is either "you can't" or "interop with C". In D, 
> the answer is "oh, you can totally do that, just this won't work, and 
> this is needed, and this will probably not compile, oh and no one tested 
> that". It adds a lot of cognitive overhead, and unfortunately there are 
> many points of division like that. @nogc/RC, GC, add to that -betterC 
> too. Which one would a "new" Phobos support? I don't think you can 
> support them all. You'd have to go for the lowest common denominator, 
> which is @nogc, but if stdlib doesn't require a GC, what is the point of 
> a GC at all. 

This can be solved by pushing the allocation up the call stack. Instead 
of having a function allocate memory, pass a buffer, delegate, output 
range or something similar to the function. Then whatever you pass can 
decide if it should allocate using the GC, malloc or something else.

This will make the API not as nice to work with. But a layer on top of 
that can be built with a default allocation strategy. I would suggest 
the default allocation strategy to be the GC. If someone doesn't want to 
use the GC he/she can use the layer below and decide how the allocation 
should be done.

> Also, some language features seem dubious or hardly used at all. Does 
> anyone really use contracts? I know they're sweet and Eiffel and 
> everything, but does anyone ACTUALLY use them and doesn't stick to good 
> old asserts? Perhaps rather than implementing (and supporting! each 
> feature has to work well with other features which adds support 
> overhead) such features, it'd be more useful to add features like struct 
> initialization outside of assginments, which feels to me like a much 
> nicer improvement to the language.

I use contracts. But with the current implementation it's only a 
syntactic difference between an in-contract and a regular assert inside 
the function body. Instead, the in-contract should be called by the 
caller, not the callee.

-- 
/Jacob Carlborg