On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
> On 5/26/2020 11:20 PM, Bruce Carneal wrote:
>> I'm not at all concerned with legacy non-compiling code of this nature.
>
> Apparently you agree it is not an actual problem.

Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me.

-- Bastiaan.

On 5/26/2020 12:18 AM, Johannes Loher wrote:
> 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.

It is a fair point. But I am looking a bit farther than that - the team that is responsible for QAing software (sometimes it is a separate team). The QA team cannot tell the difference between correctly annotated @trusted code and greenwashed code.

But they can tell when code is not annotated (no, it is not harder to do, the annotations are designed to not be hidden - annotations cannot be hidden by the preprocessor nor are they propagated from imports. They have to be there, and if grep doesn't find them, they are not there. I've never had any difficulty finding the annotations belonging to a declaration).

Un-annotated C declarations should be a red flag to any competent QA team. Recognizing a false @trusted is a whole lot harder.

BTW, one good thing that has come out of this issue is people are strongly in favor of what @safe does. That bodes well for DIP1000 and the @live code, for a long time I seemed to be the only one who cared about it.

I also have no problem if the D style checker checked for un-annotated C declarations. That's the kind of thing it's for.

On 27.05.20 11:34, Bastiaan Veelo wrote:
> On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
>> On 5/26/2020 11:20 PM, Bruce Carneal wrote:
>>> I'm not at all concerned with legacy non-compiling code of this nature.
>>
>> Apparently you agree it is not an actual problem.
> 
> Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me.
> 
> -- Bastiaan.

It's just selective reading and confirmation bias.

Walter did not read past the quoted sentence as it successfully slaughters the straw man he set up in his previous post.

On 27/05/2020 9:50 PM, Walter Bright wrote:
> BTW, one good thing that has come out of this issue is people are strongly in favor of what @safe does. That bodes well for DIP1000 and the @live code, for a long time I seemed to be the only one who cared about it.

Most of the arguments against @safe by default I have seen over the years (including from me) originate in /how/ to make it default, not in it becoming the default.

For me at least, I will not ever want to use @live, pointers with multiple behaviors depending on how it is used which don't change the syntax? No thanks, I thought we had learned that was a bad idea.

But a head const storage class that handles lifetimes with no extra syntax thanks to DIP25/1000, yes please! I will use that.

On 27.05.20 07:54, Walter Bright wrote:
> On 5/26/2020 1:32 PM, Paul Backus wrote:
>> The reason extern function declarations are particularly problematic is that changing them from @system-by-default to @safe-by-default can cause *silent* breakage in existing, correct code.
> 
> Can you post an example of currently compiling and correctly working code that will break?
> 
> Setting aside use of __traits(compiles, ...).

What exactly is your standard here? Are you saying we have to produce the following?

- Monolithic example, API breakage does not count.

- No __traits(compiles, ...)

- The code has to compile under both old and new rules.

- The code has to corrupt memory in @safe code under new rules.

This is clearly not possible, exactly because the old @safe rules are stronger. But why exactly should API breakage not count?

On 5/26/2020 5:20 AM, 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. 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.

Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish.

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

I do, too. But apparently not by typing.

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

People who require correctness are going to have to manually audit each and every C declaration regardless. There's no way around it. A less strict auditor would focus his attention on un-annotated declarations and assume that annotated ones are annotated correctly.

On 5/26/2020 6:07 AM, Panke wrote:
> 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.


Thank you, it is nice to see this.

On 27/05/2020 10:03 PM, Walter Bright wrote:
> Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish.

Okay, how is your camera and mic situation?

Lets do a Twitch stream, make sure there are some moderators in place as well.

Open to everybody and it can be recorded by Twitch.

Am 27.05.20 um 11:50 schrieb Walter Bright:
> It is a fair point. But I am looking a bit farther than that - the team that is responsible for QAing software (sometimes it is a separate team). The QA team cannot tell the difference between correctly annotated @trusted code and greenwashed code.
> 
> But they can tell when code is not annotated (no, it is not harder to do, the annotations are designed to not be hidden - annotations cannot be hidden by the preprocessor nor are they propagated from imports. They have to be there, and if grep doesn't find them, they are not there. I've never had any difficulty finding the annotations belonging to a declaration).
> 
> Un-annotated C declarations should be a red flag to any competent QA team. Recognizing a false @trusted is a whole lot harder.

This is a very specific situation. There are a lot of teams / developers that do not work in this manner. I don't know the numbers so I will make no statement about what is more common but my personal experience is a different one.

Also what is the difference between your QA department telling you to correctly annotate C declarations and the compiler telling you that? If you expect people to ignore what the compiler is telling them, why do you expect them to listen to the QA department? In my opinion, the compiler actually _is_ one of the best QA departments.

Also in my opinion, a competent QA department should carefully look at any @trusted code /declarations. Maybe it is not a "red flag" but it is definitely something that needs to be checked with extra care.

Am 27.05.20 um 11:25 schrieb Walter Bright:
> On 5/24/2020 3:40 AM, Stefan Koch wrote:
>> The distinction is that you can find a slapped on trusted with a grep.
> 
> It's just as easy to use grep to *not* find @trusted.

But that's not enough. You need a regexp that searches for extern
(C(++)) declarations that do not have any of @safe, @trusted, @system.
The attributes can also be either before the return type + name +
parameters or after it. They can also be mixed with any other
attributes. Sure, you can probably write a regex that matches all of
this but it is a _lot_ more complicated than simply searching for @trusted.