On 24.05.20 02:55, Arine wrote:
> That works even if you make the static this() @safe, and remove the pointer incrementation.

Sure. `*p = 13;` is perfectly @safe. The static constructor isn't needed for that part. You can just as well do the assignment in `main`. The static constructor is another feature that can smuggle unsafe code (the increment) into your program without the @trusted warning label.

> You'd have to make the p initialization @safe.
> 
>      @safe:
>          int* p = cast(int*) &x; // error
> 
> But note this doesn't work:
> 
>      @safe int* p = cast(int*) &x; // compiles
> 
> Having the default become @safe will help detect this, as I don't imagine that is a whole lot of usage of @safe: to begin with.

The example compiles with `-preview=safedefault`. And even if that gets changed, it will probably still compile when marked @system. So we still won't find it when looking for "@trusted".

I'd like to emphasize:

1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe.

2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons.

3. Un-annotated declarations are easily detectable in a code review.

4. Greenwashing is not easily detectable in a code review.

5. Greenwashing doesn't fix anything. The code is not safer. It's an illusion, not a guarantee.

6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to. Hence it's more likely to be correct than when greenwashed.

7. D should *not* make it worthwhile for people to greenwash code.

It is, in a not-at-all obvious way, safer for C declarations to default to being safe.

On 24.05.20 05:28, Walter Bright wrote:
> I'd like to emphasize:
> 

I understand all of those points and most of them are true, and obvious.

The issue is that they are not a justification for the decision. You seem to think that greenwashing is not greenwashing when it is done by the compiler without user interaction. Why is that?

> 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe.
> ...

Which is exactly why it should not be possible to declare it @safe.

> 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons.
> ...

Slapping @safe on it should not even compile. You should slap either @system or @trusted on it.

> 3. Un-annotated declarations are easily detectable in a code review.
> ...

It's easier to find something that is there than something that is not there. Greenwashing is not easier to detect if the compiler did it implicitly.

> 4. Greenwashing is not easily detectable in a code review.
> ...

Even though it is easy to miss in a code review, it's easy to detect automatically. Any extern(C) prototype that is annotated @safe (explicitly or implicitly) is greenwashed.

> 5. Greenwashing doesn't fix anything. The code is not safer.

Actually further down you say that it makes the code safer in a "not-at-all obvious way". Which is it?

> It's an illusion, not a guarantee.
> ...

Yes. On the other hand, @trusted is not an illusion, it is a way to clarify responsibilities.

> 6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to.

True, but this is an argument against restrictive defaults in general, in particular @safe by default. Also note that if someone cares to annotate declarations, the compiler pointing out missing annotations that would otherwise cause implicit greenwashing is _useful_.

> Hence it's more likely to be correct than when greenwashed.
> ...

This is true whether or not the compiler does the greenwashing implicitly. Annotating with @safe is a lie, whether the compiler does it or the programmer. It should be rejected and force @system or @trusted. You can still quickly see a difference in applied care by checking whether it's a single @trusted: or each prototype is annotated individually.

> 7. D should *not* make it worthwhile for people to greenwash code.
> ...

Greenwashing automatically is not a solution, it's admitting defeat. Why can't the compiler just reject greenwashing with @safe?
Slapping @trusted on prototypes is not greenwashing, it's saying "I take responsibility for the memory safety of this external C code".

> It is, in a not-at-all obvious way, safer for C declarations to default to being safe.

@safe is advertised to give mechanical guarantees, where @trusted is a way for programmers to take responsibility for parts of the code. It is not advertised to be an unsound linter with pseudo-pragmatic trade-offs and implicit false negatives.

On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
> I'd like to emphasize:
>
> 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe.

Agree completely.  Not in dispute that I've seen.  In the same vein, defaulting a declaration to @safe doesn't make it safe.

For the ultra paranoid, even the name mangling in D libraries is not to be trusted because "the implementation is not available".

>
> 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons.

I don't believe that you or any other competent programmer greenwashes safety critical code.  Regardless, the safety conscious must review their dependencies whatever default applies.

>
> 3. Un-annotated declarations are easily detectable in a code review.

Automating this for the transitive closure of defaulted @safe functions would help.  Maybe that capability is there already and I missed it?

> [snip]
> It is, in a not-at-all obvious way, safer for C declarations to default to being safe.

I agree that it is not-at-all obvious.

On a positive note, the DIP discussion/clarification should encourage the safety conscious to rebase code to a machine checkable form whenever feasible.

On 24/5/20 5:28, Walter Bright wrote:
> I'd like to emphasize:
> 
> 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe.
> 

Here, I agree with Timon: only @system and @trusted should be possible, and in my personal view it should be mandatory to annotate external declarations. If not, at least default to `@system`.

> 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons.
> 

So the compiler helpfully does the "greenwashing" for us. How is that an improvement in any way?

> 3. Un-annotated declarations are easily detectable in a code review.
> 

No, they are not. If somebody slaps `@trusted:` at the beginning of a file, that's a conscious decision, there will be a commit for that. Fingers can be pointed and questions asked.

If the compiler silently does it's highly likely that many people won't notice, and at the very least there will be plausible deniability ("sure, boss, I didn't know you had to slap `@system` to our C declarations, also, I was using @safe and the compiler didn't complain").

> 4. Greenwashing is not easily detectable in a code review.
> 

I would say that greping for `@trusted:` is no that hard. I'm pretty sure tools like d-scanner are more than able to catch the more advanced cases.

> 5. Greenwashing doesn't fix anything. The code is not safer. It's an illusion, not a guarantee.
> 

Yet the compiler will just do it, breaking all the promises for `@safe` code in the process. Now the whole `@safe` concept becomes the same "illusion".

> 6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to. Hence it's more likely to be correct than when greenwashed.
> 

Q.E.D.

How come this doesn't apply to the compiler?

> 7. D should *not* make it worthwhile for people to greenwash code.
> 

Then just disallow blanket greenwashing at all. You're just making the case for forbidding `@trusted:`, and that's something I'd totally support.

Or make it so that function declarations need

> It is, in a not-at-all obvious way, safer for C declarations to default to being safe.

It's definitely one of most not-obvious things I've ever seen here.

On Sunday, 24 May 2020 at 06:26:56 UTC, Bruce Carneal wrote:
> On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
>> [snip]
>> 3. Un-annotated declarations are easily detectable in a code review.
>
> Automating this for the transitive closure of defaulted @safe functions would help.  Maybe that capability is there already and I missed it?
>

This tooling up to try and mitigate the damage caused by the DIP would not be necessary were Timon's model followed.

After reading Timon's latest I've regained hope that this could still work out well.

On Sunday, 24 May 2020 at 05:43:45 UTC, Timon Gehr wrote:

> @safe is advertised to give mechanical guarantees, where @trusted is a way for programmers to take responsibility for parts of the code. It is not advertised to be an unsound linter with pseudo-pragmatic trade-offs and implicit false negatives.

And turns back to my previous question, that Walter (or Atila) never replied: what I need to reply back to customers asking us about @safe.

@safe is for mechanical check or not?

An official and public declaration please.

/P

I infer your position is the idea that putting @trusted on the declarations isn't greenwashing, while @safe is.

I can't see a practical difference between:

@safe extern (C) void whatevs(parameters);
@trusted extern (C) void whatevs(parameters);

Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user.

On 5/23/2020 11:26 PM, Bruce Carneal wrote:
> I don't believe that you or any other competent programmer greenwashes safety critical code.  Regardless, the safety conscious must review their dependencies whatever default applies.

That's the theory. But we do, for various reasons. I've seen it a lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way.

We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly.

On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote:
> I infer your position is the idea that putting @trusted on the declarations isn't greenwashing, while @safe is.
>
> I can't see a practical difference between:
>
> @safe extern (C) void whatevs(parameters);
> @trusted extern (C) void whatevs(parameters);
>
> Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user.

I've always understood that the @safe,@trusted,@system machinery provides the following guarantee once all holes are fixed:

If I have a memory corruption in my code than I need to only look at the @trusted and @system parts to find it.

Marking whatevs @safe violates this, marking it @trusted does not.