The D Programming Language Vision Document

[ag0aep6g]

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.