On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> On 5/25/2020 7:04 PM, Johannes Loher wrote:
>> Now let's compare the two different options:
>> 
>> 1. With DIP1028 in its current form, the code will compile and a memory corruption will actually happen. The problem might be extremely difficult to track down for the developer because he has no clues whatsoever where to start looking.
>> 
>> 2. With one of the solutions that were presented, the code will not compile as it is. According to your argument of „convenience“, the developer will probably just mark the function incorrectly as @trusted which makes the code compile. The memory corruption will happen. However, even if the developer did not think much about potential safety issues when adding @trusted to the function, he now still remembers that he did that (it was a conscious decision, even if it was a careless and lazy one). He has a clear point to start looking for the reason of the memory corruption.
>> 
>> Do you honestly think option 1 is better?
>
> Yes, for reasons I carefully laid out.
>
> > no clues whatsoever
>
> He can look at unattributed declarations.
>
> The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts.

I think this is what's the most frustrating part. You aren't actually taking criticism if you cherry-pick what you reply to.

On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
> On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
>> A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.
>
> Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful.

Doesn't work for templated functions since their @safety might depend on the the particular instantiation (consider std.algorithm.map).

On 26.05.20 13:09, Atila Neves wrote:
> On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
>> On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
>>> A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.
>>
>> Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful.
> 
> Doesn't work for templated functions since their @safety might depend on the the particular instantiation (consider std.algorithm.map).

I think the point was that annotating with @safe liberally should not enable memory corruption.

On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> [..]

Thank you very much for your patience with all the negative feedback. I get your decision to not annotate extern C with @system by default. The biggest issue with extern @system is that @trusted would become less useful when dealing with declarations and bindings. @trusted would appear more frequently. We wouldn't be able to assume that the author put in effort in assessing the trustworthiness of a declaration. More greenwashing, less safety. Those are severe drawbacks, I agree.
However, as Andrei pointed out, PR is a huge problem. We need to be able to sell it with a straight face.
I think this might be done by formally redefining the meaning of safety attributes when applied to extern:
The safety of extern can't be assessed by the compiler. Implicit "@safe" extern within @safe code is accepted for the convenience of the average user. Explicit @system or @trusted can be added for desired behavior.
I think this can be explained.
It's not an acceptable solution for people who require correctness. ZombineDev can't tell an auditor that he relies on D-Scanner to find the problematic spots. I believe it's unavoidable to provide an option to change the default. It could make extern @system or refuse to compile safe code calling @safe extern.

On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote:
> On Monday, 25 May 2020 at 23:39:33 UTC, Andrei Alexandrescu wrote:
>> [..]
>
> Thank you, Andrei, you've put this quite eloquently. With more than 200+ replies, unfortunately, this whole discussion looks like an excessively inefficient use of the community's time.
>
> One way to resolve this stalemate (which I've proposed in another post) is to split off the point of contention from DIP1028. In other words, amend the newly proposed compiler switch `-preview=safedefault` to not change the meaning of non-extern(D) function declarations and introduce a new compiler switch `-implicitly-{safe,trusted}-extern-fn-decls` (*) that adds the automatic "greenwashing" functionality that Walter desires so much.

If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true.

Am 26.05.20 um 14:20 schrieb Johannes T:
> Thank you very much for your patience with all the negative feedback. I get your decision to not annotate extern C with @system by default.

As much as i disagree with the decision, I am still very glad that we are at least having a discussion. I also want to thank Walter for participating here. I understand this can be difficult but it is the right thing to do.

> The biggest issue with extern @system is that @trusted would become less
> useful when dealing with declarations and bindings. @trusted would
> appear more frequently. We wouldn't be able to assume that the author
> put in effort in assessing the trustworthiness of a declaration. More
> greenwashing, less safety. Those are severe drawbacks, I agree.
> However, as Andrei pointed out, PR is a huge problem. We need to be able
> to sell it with a straight face.
> I think this might be done by formally redefining the meaning of safety
> attributes when applied to extern:
> The safety of extern can't be assessed by the compiler. Implicit "@safe"
> extern within @safe code is accepted for the convenience of the average
> user. Explicit @system or @trusted can be added for desired behavior.
> I think this can be explained.

Well, the spec actually already mentions that:

> Safe External Functions
>
> External functions don't have a function body visible to the compiler:
>
> @safe extern (C) void play();
>
> and so safety cannot be verified automatically.
> Best Practices: Explicitly set an attribute for external functions
rather than relying on default settings.

I still don't think this is the correct thing to do. Instead, annotating
external (at least extern(C)) functions with @safe (implicitly as the
default or explicitly) should be a compile error in my opinion.

> It's not an acceptable solution for people who require correctness. ZombineDev can't tell an auditor that he relies on D-Scanner to find the problematic spots. I believe it's unavoidable to provide an option to change the default. It could make extern @system or refuse to compile safe code calling @safe extern.

A switch might help but the whole purpose of this DIP is to get the defaults right. In my opinion, such a switch should be enabled by default. There is also the danger of creating 2 versions of the language that are incompatible with each other. Only giving this a quick thought, I believe it could work (you can still link libraries compiled with and without the switch) but I'm not completely sure.

On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
> On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote:
>> [...]
>
> If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true.

-preview=safe now
-revert=safe "tomorrow"

On Tuesday, 26 May 2020 at 12:20:31 UTC, Johannes T wrote:
> On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
>> [..]
>
> Thank you very much for your patience with all the negative feedback.

Yes, good think to stop once in a while and appreciate it. "To not complain is sufficient praise", does not always cut it.

On Tuesday, 26 May 2020 at 12:38:54 UTC, Johannes Loher wrote:
> A switch might help but the whole purpose of this DIP is to get the defaults right. In my opinion, such a switch should be enabled by default. There is also the danger of creating 2 versions of the language that are incompatible with each other. Only giving this a quick thought, I believe it could work (you can still link libraries compiled with and without the switch) but I'm not completely sure.

The bazel community has lots of such switches. Basically every new behaviour get's introduced with a --preview switch, that will turn into a --revert after some time.

For each switch there is a github issue, explaining the change it detail. Why it was necessary, what the changed behaviour is, how to migrate and the timeline for this particular switch.

Am 26.05.20 um 15:10 schrieb Panke:
> 
> The bazel community has lots of such switches. Basically every new behaviour get's introduced with a --preview switch, that will turn into a --revert after some time.
> 
> For each switch there is a github issue, explaining the change it detail. Why it was necessary, what the changed behaviour is, how to migrate and the timeline for this particular switch.

D has the same thing (e.g. -preview=safedefault will enable this DIP). The main difference to Johannes T's suggestion is that these preview and revert switches are only a temporary measure to ease the transition. They do not create different versions of the language permanently.