Maybe D is right about GC after all !

[rjframe]

On Thu, 28 Dec 2017 00:57:41 +0100, Timon Gehr wrote:

> On 27.12.2017 16:37, rjframe wrote:
>> If the programmer opts-in to those checks... it's a +1 for pragmatism
>> but does make marketing the language a bit weird -- one-liners spawn
>> objections to the integrity of the claim (such as a portion of this
>> thread; if there are objections within the community, how much more
>> will we find objections outside it!).
> 
> Frankly, I can see no need to appeal to people who think that having a
> culture where people feel free to question claims they consider dubious
> somehow reflects badly on the community or the language (hint: it's the
> opposite).


I must not have explained my thoughts very well there.

My point is that if people that have already begun using the language 
aren't certain it's being accurately described, we can (should?) expect 
those who haven't chosen to learn the language to think the same. But if 
they think it's being misrepresented, they may just decide not to bother. 
We have to be careful to be accurate, and we unfortunately don't get to 
control the definitions of the words we use.

To say that D should become memory-safe by default (as many do) is to 
claim it is not currently memory-safe by default; so can D be called a 
memory-safe language? E.g., would the claim that "D is memory-safe" be 
commonly-interpreted to mean "D is memory-safe by default"?

The MSVC compiler does buffer security checks, by default, in release 
builds[1]. I believe clang lets you add bounds checks via a compiler flag. 
Do these make C++ a memory-safe language? (answer: definitely not)


I think the dlang.org home page description in the "Run Fast" section is 
perfect, or at least nearly so. But I don't think a simple "D is memory-
safe" is even true.


[1]: https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-
security-check