On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote:
"“But D has a GC!”, I hear you exclaim.
No body said that. Funny how you chose the simplest argument to
argue against.
Yes, but it’s also a
systems programming language with value types and pointers,
meaning that today, D isn’t memory safe. DIP1000 was a step in
the right direction, but we have to be memory safe unless
programmers opt-out via a “I know what I’m doing” @trusted
block or function. This includes transitioning to @safe by
default."
https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
-Alex
Despite the mess DIP1000 was and still is, it did actually solve
some problems. Even still there are bugs related to DIP1000 that
aren't being fixed anymore cause the focus has already shifted
away from it. The DIP1000 still says it will be "updated" but
that's most likely never going to happen. Especially considering
this DIP1021 has an example of a bug that the DIP doesn't even
fix.
For @safe, it is already safe if you use the GC. If you use @safe
with DIP1021 you are restricting the user in what code they can
write and it doesn't make their code any safer. This is just a
flat restriction for no purpose for them.
For manual memory management, this does not solve the problem
illustrated by the DIP's example. Especially considering that in
a blog post (formally unbeknownst to the DIP1021) the intention
is to introduce a @live attribute. And the actual problem won't
actually be fixed unless the @live attribute is there.
So it doesn't benefit @safe users, it doesn't benefit manual
memory management users and it won't come to fruition until some
future attribute is implemented. I'm all for implementing Rust's
memory management in D, but this is just horrible project
management in all regards. Maybe it wouldn't be that big of a
deal if it was a smaller project where you can muddle through
finding your way willy nilly, but the whole purpose of the
formalities -is- should be so you don't do that.
