On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
>> [..]
>> But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion.
>> [..]
>
> The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle.
> I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen.
> I don't like @safe extern, but it seems like the lesser evil. Walter got a lot of flak. I tried to retrace his thoughts and see the merits.

there is no such thing as a trustworthy @trusted. not with how the whole safety system work now.
you can break previously verified @trusted code by just writing @safe code today.

On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote:
> On 25.05.20 11:25, Johannes T wrote:
>> @trusted can't be trusted
>
> That's the point of @trusted. ._.
>
> The code is trusted by the programmer, not the annotation by the compiler.

Sorry, I phrased it poorly. I meant @trusted would be used more frequently. The focus would spread and lead to less rigorous checks.

On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote:
>
> there is no such thing as a trustworthy @trusted. not with how the whole safety system work now.
> you can break previously verified @trusted code by just writing @safe code today.

Do you have an example of code that was correctly labeled @trusted in DMD version X, which may not be labeled @trusted in DMD version Y because of changes to @safe/@trusted@/@system?

On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
>> [..]
>> But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion.
>> [..]
>
> The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle.
> I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen.
> I don't like @safe extern, but it seems like the lesser evil. Walter got a lot of flak. I tried to retrace his thoughts and see the merits.

From my perspective it is really simple: Either we have a strict @safety system (with exactly one escape hatch) or we don't. At the moment we don't because you can have @safe extern(C) declarations but with this DIP it becomes even worse as it is more likely that @safe promises are broken without anybody noticing.

If you and more importantly Walter and Atila really think this is the lesser evil and that it is worth dropping the strict @safety system with exactly one controlled escape hatch for this, then we also need to clarify what @safe means after that. We can definitely not claim that it means machine verified except for @trusted because extern(C) functions are another escape hatch. The question has been asked in this thread a few times already: What does @safe actually mean? How to „sell“ / „advertise“ it?

On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
> On 25/05/2020 10:29 PM, Zoadian wrote:
>> you complain about @trusted losing it's meaning, but @safe was ment to mean "mechanically verified memory safety". it should be forbidden to add @safe to any function that can not be verified by the compiler.
>
> It is meant to mean that at some point it has been mechanically checked by the compiler.
>
> Either during current compilation or a prior one.
>
> Which means it has to be valid on function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise.

.di files _could_ just use @trusted instead of @safe. but for extern(D) we could at least add it to the name mangling. it's still not 100% safe, but at least you'd have to work hard to get it wrong.

On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote:
> [..]
> there is no such thing as a trustworthy @trusted.
> [..]

Sorry, my bad. I meant the quality of @trusted annotations would decline.

On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
> On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
>> It is meant to mean that at some point it has been mechanically checked by the compiler.
>>
>> Either during current compilation or a prior one.
>>
>> Which means it has to be valid on function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise.
>
> .di files _could_ just use @trusted instead of @safe. but for extern(D) we could at least add it to the name mangling. it's still not 100% safe, but at least you'd have to work hard to get it wrong.

It's been proposed before that @safe and @trusted should have the same mangling, since there's no difference between them from the calling code's perspective.

On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
>> [..]
>> But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion.
>> [..]
>
> The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle.

Wrong. The quantity of untrustworthy code remains the same, but with DIP1028 (at least in the current form) the compiler sweeps the previously @system code under the rug and makes it harder for those who care about safety to trust @safe.

@safe must mean only one thing: compiler verified. Or otherwise needing less manual review. @system and @trusted means that code review should be prioritized. @safe non-extern (D) marked either by the programmer, or the implicitly by the compiler should be disallowed as it *is* greenwashing.

> I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen.

It didn't happen, because it didn't need to. Naturally, most things go through the path of least resistance. Most developers are coming from other languages where they have never had the requirement to write @safe code [external pressure]. Also previously, @safe wasn't the default for D function definitions, so there was less [internal pressure] to do so. With @safe being the default of function definitions, it's more difficult to leave code as @system (of course, modulo @trusted).

> I don't like @safe extern, but it seems like the lesser evil.

No, @safe extern is the worst possible option! It basically makes @safe meaningless.

> Walter got a lot of flak. I tried to retrace his thoughts and see the merits.

On several occasions (e.g. on Reddit) I have defended Walter from unfair accusations, however, in this case, he's rightfully criticized.
He seems to think that he's taking an unpopular decision for the greater good, but that's not the case. @safe-by-default on D function definitions could be considered an unpopular decision for the greater good. Implicitly @safe non-extern(D) functions is greenwashing, where the responsibility for the action is removed from the developer by a compiler switch. That's basically negating all the benefits of @safe-by-default on function definitions.

On 25.05.20 14:22, Johannes T wrote:
> On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote:
>> On 25.05.20 11:25, Johannes T wrote:
>>> @trusted can't be trusted
>>
>> That's the point of @trusted. ._.
>>
>> The code is trusted by the programmer, not the annotation by the compiler.
> 
> Sorry, I phrased it poorly. I meant @trusted would be used more frequently. The focus would spread and lead to less rigorous checks.

This is just not true. If the compiler forces you to decide to put either @trusted or @system, then you will not get more usage of @trusted than if it implicitly decides for you that what you want is implicit @trusted.

On 25.05.20 14:22, Johannes T wrote:
> Sorry, I phrased it poorly. I meant @trusted would be used more frequently. The focus would spread and lead to less rigorous checks.

The focus is as wide as it's ever been. If you want to verify a program, you have to check those prototypes, whether they're explicitly @trusted or implicitly @safe. @safe-by-default only makes them harder to find.