Blog: GC

[Dukc]

On Sunday, 7 March 2021 at 07:10:30 UTC, Rumbu wrote:
>
> First, library solutions show the lack of commitment from 
> language creators. There is a big difference between "This is 
> how to do X in D" and "This is one idea how to do X in D. Use 
> this library. Or maybe not, probably there are other options". 
> The latter makes programmers insecure regarding the *correct* 
> approach when they want to do something.
>
> Secondly, basic language constructs must be available in the 
> core language not in a library, even if it's just druntime in 
> this case. Putting them in the library makes the language 
> unusable without that library.

I'd agree with these if we were talking about a DUB package, but 
the standard library is called standard for a reason. It's one of 
the language maintainers (Atila) that also decides what will get 
to Phobos, so Phobos solutions are not outsourced solutions.

As for the language being unusable (or rather, less usable) 
without Phobos, I highly prefer it against more stuff being in 
the compiler. First off, it's not like you either use all of 
Phobos or no Phobos at all. Even a runtimeless device driver 
could easily use parts std.algorithm and std.range, since they 
are templated and do not depend on being linked to anything.

Second, if something does not work in Phobos, you can just avoid 
using it and work around the problem. Often it's even practical 
to give your workaround the same API as the Phobos equivalent. I 
know because I have worked with compiling to WASM. If that 
non-working feature were in the Druntime, you suddently get 
obscure errors, often from the linker, due to required DRuntime 
symbol missing. And if the compiler had the non-working feature, 
you'd have to patch and recompile the compiler before you can 
even start the real work!