If you needed any more evidence that memory safety is the future...

[Moritz Maxeiner via Digitalmars-d]

On Friday, 3 March 2017 at 02:48:46 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 03/02/2017 06:00 PM, Guillaume Piolat wrote:
>> On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner 
>> wrote:
>>> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer 
>>> wrote:
>>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>>>
>>>> [...]
>>>
>>> This isn't evidence that memory safety is "the future", 
>>> though.
>>
>> Completely agreed.
>> This only shows that memory safety is not the present. Not 
>> that it is
>> "the future".
>
> I think it's safe enough to just go ahead and interpret it as 
> "...evidence that memory safety is important and SHOULD be the 
> direction we take."

I agree with the sentiment that taking that direction is likely 
to yield significant benefits in the long run for both 
developers, as well as end users. But "important" is another one 
of those things that are entirely dependent on one's viewpoint.
If I have a business that incorporates a risk analysis based on 
penalties due to past bug occurrences and likely presence of more 
bugs in my software and come to the conclusion that investing in 
a transition to a memory safer language (however we define that) 
is just not worth the associated costs then it's not important 
for me.
I'll assume for the moment, though, that with you mean the D 
community and the direction D should take in the future. In which 
case I agree, though technically a correct garbage collector is 
memory safe by definition (unless I missed something).
What kind of changes to D (spec, druntime, phobos) would you 
envision (I'm honestly curious)? And are they possible without 
breaking existing user code (because I don't think that with the 
current userbase size D can survive yet another break of the 
phobos/tango, D1/D2 dimensions)?

>
> It's English, not an ISO RFC.

Interpretations in engineering are often necessary (I'm looking 
at you, ISO "specification" 7814-4), but in a technical 
discussion I don't want to interpret. I want to discuss the topic 
at hand; and I consider hyperboles such as "X is the future" to 
be detrimental to the effort of X, whatever X is. And besides, 
while I consider memory safety to be important and use it 
whenever viable, unless there is sufficient proof that people 
using languages with memory safety builtin actually produce 
memory safe(r) programs we don't have a leg to stand on.
And while this may seem an intuitive and reasonable hypothesis, 
it's still something that has to be proven; one current case 
shows to me, at least, that people writing Rust code can (and 
sometimes do) make the same kinds of mistakes they would've made 
in C regarding memory safety[1]. Which does not suprise me, 
honestly, since all of these languages I'm aware of currently 
allow you to expose a "safe" API over "unsafe" internal mechanics 
(or in the linked example the other way around) and if the unsafe 
code is broken you're screwed. Period.
The only kind of language for which I'd implicitly accept the 
conclusion that writing in it produces more memory safe programs 
than in others is one where unsafe operations are utterly 
forbidden. This, of course, is impractical, since it means no C 
interop and would make such a language more or less irrelevant.

[1] 
https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-phase1-20170208.pdf