On 5/24/2020 5:56 PM, Timon Gehr wrote:
> It's only greenwashing if it's misleading. Putting @safe is a lie, putting @trusted is honest.

It is not honest unless the programmer actually carefully examined the interface and the documentation to determine if it is a safe interface or not. For example, labeling memcpy() with @trusted is not honest.

Forcing people to add uncheckable annotations is a path to convenience, not honesty.

On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote:
> On 5/24/2020 5:56 PM, Timon Gehr wrote:
>> It's only greenwashing if it's misleading. Putting @safe is a lie, putting @trusted is honest.
>
> It is not honest unless the programmer actually carefully examined the interface and the documentation to determine if it is a safe interface or not. For example, labeling memcpy() with @trusted is not honest.
>
> Forcing people to add uncheckable annotations is a path to convenience, not honesty.

This has already been repeated over and over again but I'll do it once more:

If people cannot check the code (or get enough confidence in another way), they really shouldn’t annotate it with @trusted but with @system instead. If they annotate it with @trusted anyways, it is their own fault. And at least in that case they are lying and not the compiler. Also if something bad actually happens, they can at least search for „high risk areas“ (@trusted declarations).

Just consider the following situation:

A (maybe inexperienced) programmer needs to call an existing C function from D code. Because no bindings exist yet, he creates them himself. He does not add any annotations regarding safety. Now he uses this function in @safe code and he uses it in a way that actually creates a memory corruption (the function is not  safe, but the developer does not know about that).

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?

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.

On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> On 5/25/2020 7:04 PM, Johannes Loher wrote:
[..]
>> 
>> Do you honestly think option 1 is better?
>
> Yes, for reasons I carefully laid out.

which fails to convince anyone because the reasoning is flawed.

>
> > 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.

Unattended automatic greenwashing by the compiler is WORSE!

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.

A direct response to Andre's thorough critique of your reasoning would be appreciated.

>
> > no clues whatsoever
>
> He can look at unattributed declarations.

Again, as many have noted, putting a coverage problem like this on the programmer is problematic.

>
> The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts.

Greenwashing is bad.  En masse greenwashing by the compiler, as mandated by the DIP currently, is really bad.

On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote:
> On 5/24/2020 5:56 PM, Timon Gehr wrote:
>> It's only greenwashing if it's misleading. Putting @safe is a lie, putting @trusted is honest.
>
> It is not honest unless the programmer actually carefully examined the interface and the documentation to determine if it is a safe interface or not. For example, labeling memcpy() with @trusted is not honest.
>
> Forcing people to add uncheckable annotations is a path to convenience, not honesty.

What is the difference of @safe to @trusted in that respect? Does the compiler "carefully examines" any interface or documentation?

Why not simply introducing new label as a solution, something in the realm @extern_safe_dont_know?

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.

(*) I think that `-implicitly-safe-extern-fn-decls` would be lie, but `-implicitly-trusted-extern-fn-decls` I can tolerate.

On Tuesday, 26 May 2020 at 02:04:02 UTC, Johannes Loher wrote:
> 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.

Or he'll do the right thing, and keep the function @system but call it from a @trusted block. Then when he's stuck debugging, he can show it to his experienced buddy and his experienced buddy will instantly look in the @trusted block because it's suspicious.

On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> He can look at unattributed declarations.

The issue is, you have to know about that beforehand. In the other situation, you explicitly get warned by the compiler (by the compile error) that that something dangerous is going on.

Also, this means, there are now 2 different things to look for: @trusted function declarations and unannotated extern(C) declarations. The latter is much harder to search for (as Andrei also noted in his reply) and it's just much simpler to only have one escape hatch to look out for. It is also a very weird special case. @safe means no memory corruption is possible except for any @trusted declarations and any unannotated extern(C) declarations, wrongfully @safe extern(C) declarations and wrongfully @trusted extern(C) declarations. This just doesn’t sound right.

> The whole debate boils down to "is greenwashing better, more honest, more debuggable than leaving things unattributed?" No on all three accounts.

The question should be rephrased: „Is explicit greenwashing by the developer better, more honest, more debuggable than implicit greenwashing by the compiler?“ Yes for better and more debuggable for the reasons that have already been mentioned so many times. Regarding honesty: In your variant, the compiler is dishonest,  in the other variant, the developer is dishonest.

Just think about what the developer's reaction would be in the situation I described in my last post, when he actually finds the issue.

In your variant, the developer will be questioning why the compiler did not help him at all with realizing that there might be a problem. It is very likely that he blames the issue on the compiler.

In the other variant, he will realize that this something he had been warned about by the compiler and that he made a careless wrong decision and that it is his own fault. In the future he will be likely more careful when it comes to annotating stuff with @trusted. So this even has an educational effect.

On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
> 2. Make @safe the default for _all_ declarations but still make @safe on declarations without code a compile error (because the compiler cannot verify it). This means that annotating function declarations without code with @system or @trusted is now mandatory. This is what Timon has been arguing for if I understood him correctly.

If this DIP is going to be implemented "as is", this should be added in the future.
It could also be a warning, but that is not something that D often does.
With this addition, not having a special case for extern(), is a positive.