More evidence that memory safety is the future for programming languages

Timon Gehr timon.gehr at gmx.ch
Sun Mar 29 01:59:44 UTC 2020


On 28.03.20 22:03, JN wrote:
> On Saturday, 28 March 2020 at 20:24:02 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/item?id=22711391
>>
>> Fitting in with the push for @safe as the default, and the @live 
>> Ownership/Borrowing system for D.
>>
>> We can either get on the bus or get run over by the bus.
> 
> Over time we learned that opt-in safety doesn't work and @safe should be 
> the default. Do you think the same will happen with @live?

Why would this happen? The only thing that @safe and @live have in 
common is that they are function qualifiers that add additional type 
checking. @safe is in service of an invariant (memory safety), while 
@live is not. It's just a linting tool that (from the perspective of 
memory safety) produces exclusively false positives in @safe code. Also, 
there is no way to negate it.


More information about the Digitalmars-d mailing list