On 03.07.22 10:46, Mike Parker wrote:
You can find the final draft of the high-level goals for the D
programming language at the following link:
https://github.com/dlang/vision-document
Quoting from the "Memory safety" section:
The language maintainers do not see memory safety as a fad, nor is their focus on its
implementation in the D programming language a form of "chasing" other
languages.
There's no need to be so defensive, particularly in the first sentence
of the section. Also, the "chasing" part is cryptic. What other
languages are you talking about? Why can their names not be uttered? I
know it's Rust, but other readers might not.
Just ax that sentence and start with "The language maintainers see
memory safety as a critical component [...]".
DIP 1000 is crucial to this because it eliminates most of the reasons why D
code written as simply as possible is not @safe.
Dubious claim. My experience is that people who try `scope` quickly run
into its limitations.
Eliminate undefined behavior in @safe code.
I.e., fix bugs. That's hardly worth mentioning as a high-level goal.
it's not possible to write a vector type where the following code is @safe.
auto v = vector(1, 2, 3);
v ~= 4;
That example isn't clear at all. I suppose the point is to (1) avoid the
GC and (2) still allow taking the addresses of the elements. That isn't
obvious from those two lines of code, at all. As presented, `vector` can
easily be implemented @safe-ly with a dynamic array.
Even as we strive to increase memory safety in D, we must always ensure that
programmers who need or want to eschew memory safety features can do so. And
they must be able to do so with minimal friction.
"Minimal friction" would mean not making @safe default, as that adds
friction. Little friction is the real goal.
