On 24.05.20 11:10, Walter Bright wrote:
> 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.

Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing.

On Monday, 25 May 2020 at 01:04:24 UTC, Timon Gehr wrote:
> On 24.05.20 11:10, Walter Bright wrote:
>> 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.
>
> Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing.

Yes, it would be a big nuisance.  Absent a change in the DIP the safety conscious who want to continue with D will try to back out the compiler lies as best they can: additional tooling, additional code review strictures, selective rewrites, ...

Not sure how that unfortunate future would play out exactly but it would not be pretty.  Much much better to fix the DIP.

On 2020-05-24 00:15, Walter Bright wrote:
> On 5/23/2020 4:26 AM, Faux Amis wrote:
>> Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful?
>>
>> I would definitely listen/watch; even if I were muted and could only chat maybe.
> 
> You're right, and that is the whole purpose behind DConf. It's amazing how our differences melt away when discussing with a beer in hand :-)

I meant it could be something being done more often, Dconf is (normally) only once a year. Maybe discussions like these need to be discussed more frequently.. quarterly, or even a quick official Dtalk every month :)

On 5/23/2020 5:13 AM, Steven Schveighoffer wrote:
> And let's be honest here, if you are OK with it, putting @trusted: at the top of your extern(C) functions is fine with me. At least that's not a lie.

@trusted says the interface to the function is safe. If the programmer did not actually check the interface, it is greenwashing. For example, memcpy() does not have a safe interface and marking it @trusted doesn't improve matters.

On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
> [..]

After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality.
We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom.
We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average.
We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't.
We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power.

On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
>> [..]
>
> After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality.
> We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom.
> We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average.
> We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't.
> We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power.

So basically you are saying we should do it the way it is described in the DIP because otherwise it will lead developers to incorrect usage of @trusted (just slapping it on declarations whiteout actually checking the implementation) thus making it loose its „power“ which leads to less safe code.

But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion. It makes the statement „@safe code cannot create memory corruptions except for @trusted code“ wrong (it already is wrong now but it really shouldn’t be!).

What you are describing is really just an admit of defeat. Then why still bother with @safe at all if it doesn't give us any meaningful guarantees? I don't think we are at that point (yet).

On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
>> [..]
>
> After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality.
> We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom.
> We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average.
> We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't.
> We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power.

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.

the compiler should do it's best to alert you of any mistakes you might make.
if the compiler does silently add @safe or @trusted to extern(C) functions you are are to miss annotating it. that is a bad thing for everyone that actually cares about safety.

you can't prevent programmers from doing stupid things. but you can at least warn them.

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.

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.

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.