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
