On 12/28/2019 12:22 PM, Johan Engelen wrote:
> You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that.
> 
> I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it.
> 
> I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe.

What it does mean is that all instances of #safe resulting in #undefinedBehavior should be logged either in bugzilla or noted as an exception in the #specification.

Note that there's a bugzilla keyword 'safe' which can tag them. Here's the current set of open tagged issues:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced

On 28.12.19 21:22, Johan Engelen wrote:
> On Saturday, 28 December 2019 at 13:33:25 UTC, Timon Gehr wrote:
>>
>> @safe is meant to imply no memory corruption. @safe implies no UB, because UB can lead to any behavior, including memory corruption. UB allows compilers to insert arbitrary code execution exploits. How can you call that @safe?
> 
> I think we are talking about different things here.
> 
> You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that.
> 
> I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it.

Each of those instances is a bug.

> 
> I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe.

I acknowledge that the implementation has bugs. I reported a number of frontend bugs in the type checker myself. What you are saying is that the backends have bugs as well. It's not very surprising, but I don't think you can use existing bugs in the implementation as a justification to deliberately introduce more of those bugs, which is what I read when you write "I don't buy this argument".

On 28.12.19 22:08, Walter Bright wrote:
> On 12/28/2019 12:22 PM, Johan Engelen wrote:
>> You are saying: the spec says @safe means no UB, and if the spec doesn't say it then it simply needs updating. There are a number of text pieces that say that.
>>
>> I am saying: regardless of what the spec and any of those articles promise, current D behavior is that @safe _can_ have UB in it.
>>
>> I know most people don't like to hear it nor acknowledge it. But I think it is better to be realistic about this. `@safe` currently does _not_ mean the code is super safe.
> 
> What it does mean is that all instances of #safe resulting in #undefinedBehavior should be logged either in bugzilla

Yes.

> or noted as an exception in the #specification.
> ...

Yes, but the only reasonable kinds of exceptions are invalid @trusted/@system code or specific compiler flags to disable safety (e.g. -boundscheck=off). There can't be any other exceptions.