memory management and the standard library

[Paolo Invernizzi]

On Thursday, 14 March 2019 at 21:32:21 UTC, JN wrote:
> On Thursday, 14 March 2019 at 10:02:20 UTC, Paolo Invernizzi 
> 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. Especially since GC is an issue when porting D to 
> Webassembly (need to use -betterC for that right now). I think 
> if D3 was to be successful, it'd have to be a bit more 
> opinionated. I don't mean the language has to become a OOP 
> behemoth (I'd love that though haha) or a functional monadic 
> transformer combinator, but it'd be nice to better define a 
> scope of the language and be able to answer a question "Can D 
> do XYZ?" with "No, it's not useful and you shouldn't do it this 
> way".
>
> 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.

There are a lot of changes, with large consensus, that are 
currently not admitted because of existing code.

Just **today** another one coming from Walter [1]:

"As mentioned earlier, scope guard will catch Errors, but it 
should really only catch Exceptions. This hasn't been fixed 
because there's existing code that relies on it catching Errors."

And the history of D is full of such examples, low hanging 
fruits, actionable.

/ Paolo


[1] 
https://forum.dlang.org/post/mailman.7569.1552776840.29801.digitalmars-d-bugs@puremagic.com