Maybe D is right about GC after all !

[Paolo Invernizzi]

On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote:
> On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote:
>
>> On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:
>>> The point is that the presence of one @safe: line in the 
>>> module can be mechanically checked, over one million devs 
>>> working on a codebase.
>>> 
>>> The whole point of Walter argumentation is 'mechanically'.
>> 
>> That's right. C++ is based on faith in the programmer using 
>> best practices. D is not based on faith, it can be 
>> automatically checked.
>
>
> 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!).
>
> When I hear someone talk about a memory-safe language 
> (especially as a major feature), I do think memory-safe by 
> default. The thing is, D does have support for memory-safety by 
> default (bound-checked arrays, etc.), and allows you to opt-in 
> to greater safety guarantees; but that's not what many think of 
> when they think memory-safe (it doesn't really help that every 
> language provides their own, slightly different, definition).
>
> And D has faith that programmers using @trusted know what 
> they're doing (for both writing and calling the function). 
> There is no avoiding trust in a useful language.

I prefer pragmatism over marketing all the times.

If I was a company evaluating a language, I would notice that my 
safety goal can be reached right today:

- the language guarantees that pieces of written code are memory 
safe.
- there are plenty of easy way to force that, during the 
development process.
- there's the possibility to escape this safety net to gain 
flexibility, and such part of the code can by easily searched and 
peer reviewed for memory corruption problems.

That's a big, big advancement compared to the status quo (C/C++).

It's difficult for me to comprehend why a company should not take 
advantage of it, if it cares about memory safety, only because 
@safe is not the default: that's a really _minor_ issue, compared 
to the gain of having the work done.

/Paolo