On Wednesday, 27 May 2020 at 10:40:18 UTC, Walter Bright wrote:
> On 5/27/2020 3:07 AM, Johannes Loher wrote:
>> 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.
>
> I've seen larger companies operate this way. Smaller ones cannot afford to.
>
>
>> 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?
>
> The QA dept is motivated to not be taken in by greenwashing.
>
> (Back in my days at Boeing, I worked in the design department. There was an entirely separate organization call the Stress Group. Their job was to sign off on every nitpicky detail. If they signed off on something that turned out to be wrong, it was bad for their careers. Your designs did not move forward without Stress signoff. If you tried to trick Stress, that was the end of your career at Boeing.)
>
> So yeah, there's a huge difference between tricking the compiler and tricking the QA department.
>
>
>> In my opinion, the
>> compiler actually _is_ one of the best QA departments.
>
> Indeed it is, and that's the whole point to @safe. My motivation here is make suspicious code stand out. @trusted code does not stand out so much, because it is required to exist.
>
I'm utterly confused by this.

Trusted code is always suspicious and always stands out because it is not formally verified whereas @safe code should be bulletproof. Why would anyone bother to manually check code that is supposed to be @safe? Trusted code is the villain here; wherever you see @trusted you know that the code might contain vulnerabilities because it was audited by a human and not by a machine.

If you have @safe code that has memory safety issues (from callinc C functions) then what's the point of @safe?

>
>> 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.
>
> Looking at un-annotated declarations should be the first step. If it is annotated with @trusted, at least there's the coffee stain on the drawing indicating that somebody looked at it.

On 5/27/20 6:22 AM, Walter Bright wrote:
> On 5/27/2020 3:06 AM, rikki cattermole wrote:
>> Open to everybody and it can be recorded by Twitch.
> 
> I've done the video conferencing many times over the decades. I just don't find it to be productive. Maybe it's some defect in me.
> 
> They usually go something like this:
[attempt at joke snipped]

It's safe to assume things have improved over time.

On 27/5/20 11:50, Walter Bright wrote:
> 
> 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.
> 

This is a most unsubstantiated assertion.

If this were the case, I would have to wonder what the QA team is there for, if they can just be replaced by an automatic lint tool.

*AND* even if that were so, see below:

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

Then the coder just slaps `@safe:`, `@trusted:`, or whatever greenwashing you were trying to avoid, and we're just back to square one since, per your previous assertion, QA can't notice the difference.

Heck, in such an environment I might slap `@trusted:` just in case at the beginning of each and every file and live in a land of bliss thereafter!

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

Exactly, which is why they should be disallowed by the compiler. Considering them `@system` by default is a way to do it. Another (perhaps even better) already proposed one would be to actually consider them `@safe`, but disallow `@safe` declarations where the code can't be analyzed by the compiler (it would be debatable if the mangling should be enough or not).

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

Being in favour of what @safe purports to do and in favour of what it actually does are two very different things. The whole selling point of @safe used to be "you're only responsible for `@trusted` code, now that's no longer true (or at least even less, if we account for the already existing holes).

The direction of travel is opposite to the announced destination.

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

So, if you leave them for the style checker that means that you envision cases where this could be the desired behaviour, otherwise you should just let the compiler error.

What would these cases look like? Because I can't imagine any.

On Wednesday, 27 May 2020 at 10:03:21 UTC, Walter Bright wrote:
>> 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.

A less strict auditor wouldn't have to look at un-annotated extern(C) functions if they were @system by default. It's more work for them to ensure they are actually @safe. The majority will be un-annotated if you leave it as @safe.

On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote:
> On Thu, May 21, 2020 at 05:49:27PM +0000, Paul Backus via Digitalmars-d-announce wrote: [...]

>
>> Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community.
>
> D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership.  Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future.
>
>
> T

Ha ha. I tried suggesting something like this some yrs ago as I saw it happen and deadalnix bashed me like crazy. Didn't articulate it as well as you just did though. This needs to happen.

On 27.05.20 12:51, Walter Bright wrote:
> On 5/27/2020 3:01 AM, Timon Gehr wrote:
>> This is clearly not possible, exactly because the old @safe rules are stronger. 
> 
> Thank you. We can agree on something.
> ...

I am not sure if you noticed that I agree with most of your points, just not about their relevance to the topic at hand.

>> But why exactly should API breakage not count?
> 
> I've addressed exactly this a dozen times or more, to you

No. You did not. I went over all of your responses to my posts again to make sure. Why are you making this claim?

I haven't made API breakage a central point to any of my previous posts and you did not address any of my criticism in any depth. As far as I can tell, the only point you engaged with was that @trusted is not greenwashing.

> and others. 

I don't think you did, but I am not going to check.

> Repeating myself has become pointless.
> 
> It's fine to disagree with me. Argue that point. But don't say I didn't address it.

As far as I remember, you did not address this specific point, but if I had to extrapolate your response from previous points you made I would expect your opinion to be that implicitly broken APIs should be fixed by universal manual review of not explicitly annotated functions and that this is better than the compiler catching it for you because this way only people who are competent to judge which annotation should be there will notice that it is missing.

On 28/05/2020 12:33 AM, aberba wrote:
> On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote:
>> On Thu, May 21, 2020 at 05:49:27PM +0000, Paul Backus via Digitalmars-d-announce wrote: [...]
> 
>>
>>> Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community.
>>
>> D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership.  Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future.
>>
>>
>> T
> 
> Ha ha. I tried suggesting something like this some yrs ago as I saw it happen and deadalnix bashed me like crazy. Didn't articulate it as well as you just did though. This needs to happen.

I've been saying since 2012 that we need a project manager to help with communication.

Mike has taken on parts of this role and has done quite a good job of it.

On Wednesday, 27 May 2020 at 11:46:40 UTC, Andrei Alexandrescu wrote:
> On 5/27/20 6:22 AM, Walter Bright wrote:
>> On 5/27/2020 3:06 AM, rikki cattermole wrote:
>>> Open to everybody and it can be recorded by Twitch.
>> 
>> I've done the video conferencing many times over the decades. I just don't find it to be productive. Maybe it's some defect in me.
>> 
>> They usually go something like this:
> [attempt at joke snipped]
>
> It's safe to assume things have improved over time.

Currently because COVID-19 we have (At least where I live) Politicians having meetings online and open to the public and it goes without any problems.

I've been saying this since last year, why not go for online meetings to fix things instead of only using this Forum which sometimes posts get neglected and ideas misunderstood.

Ouch this is about Technology and people don't use it the right way.

Matheus.

On Wednesday, 27 May 2020 at 05:54:32 UTC, 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, ...).

I am paraphrasing an earlier post of mine in this thread:

https://forum.dlang.org/post/yvcjpcxfyyobqubjrrxv@forum.dlang.org

The breakage is that functions which are currently correctly considered @system will instead be considered @safe. As a result, future changes to @safe code are at risk of introducing memory corruption.

Strictly speaking, the breakage does not occur until those future changes are made, so it is more accurate to say that changing un-annotated extern declarations to @safe-by-default will put existing code *at risk* of silent breakage. Given the prevalence of such declarations in existing code (e.g. [1]), I think it is inevitable that this risk will in fact lead to breakage in practice, so I do not consider the distinction particularly important to draw in this context.

[1] https://github.com/dlang/druntime/pull/3117

On Wednesday, 27 May 2020 at 10:51:54 UTC, Walter Bright wrote:
> On 5/27/2020 3:01 AM, Timon Gehr wrote:
> I've addressed exactly this a dozen times or more, to you and others. Repeating myself has become pointless.
>
> It's fine to disagree with me. Argue that point. But don't say I didn't address it.

I'm trying to understand the logic of "@safe by default for extern declaration".

So I setup a simplified real-life example that I had in my mind...

Let's say we have a project consisting of:
- an ASM file containing several function definitions (assembly language scares people away, so it's a good example).
- a .di file containing the extern(C) declarations of the former ASM functions.
- and a .d file using those functions with @safe code.

No function is annotated.

Before DIP-1028, it compiles and link without annotations.

If extern(C) decl are @system by default, it will not compile anymore, and a careless programmer will slap a "@trusted:" at the top of the ".di" file (greenwashing), and it'll stay there.

On the other hand, a careful programmer will need to annotate @trusted ONLY on functions that he actually trusts AND make the project compile anyway (because he cannot afford to leave his project broken). So what does he do to make it compile ? Should he slap a "@trusted:" at the beginning of the file just like the careless programmer and maybe explicitly annotate individually declarations that are actually trusted ? It's weird...

However, if extern(C) decl are @safe by default, he does not need to slap a "@trusted" at the top of the ".di" file, he just needs to annotate individual declarations with @trusted to advertise (to the QA, or his colleague or future self) that he reviewed successfully the function implementation, AND it will still compile.


So that example would go in favor of Walter's point. So is it a good example? Does pinpoint the point?

Because again, as the others said, it's still controversial, it's hard to sell, it's convoluted... I dunno...